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ABSTRACT 


The  ability  to  develop  information  systems  within  cost  and  schedule  is  a 
difficult  task  for  the  DoD.  The  Systems  Dynamics  Model  of  Software  Project 
Management  is  an  interactive,  computer  simulation  which  allows  for  the 
investigation  of  decision  making  in  a  software  development  environment. 

In  this  thesis  the  author  investigates  the  impact  of  risk  on  dynamic  decision 
making  in  software  project  management.  Graduate  students  participate  as  project 
managers  making  management  decisions  pertaining  to  total  staff  acquisition,  its 
allocation  to  development  versus  quality  assurance,  and  cost  and  schedule 
adjustments.  Data  analyses  reveal  that  risk  does  significantly  impact  decision 
making  and  in  turn  project  performance  in  terms  of  final  cost  and  duration. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Developing  and  maintaining  software  that  is  acceptable  to  the  end  user  continues 
to  challenge  the  Department  of  Defense  (DoD).  The  DoD  currently  spends  about  $9 
billion  each  year  on  general  purpose  automated  data  processing  equipment,  software,  and 
related  services  [Ref.  1].  With  increasingly  constrained  budgets,  improved  management 
can  lead  to  significant  cost  savings. 

The  General  Accounting  Office  (GAO)  reported  that  cost  overruns  and  schedule 
slippages  plague  DoD  systems  [Ref.  2].  Surveys  of  experienced  project  managers 
identify  personnel  shortfalls,  unrealistic  schedules  and  budgets,  and  a  continuing  stream 
of  requirement  changes  as  serious  sources  of  risk  on  software  projects.  Postmortems  of 
software  project  disasters  reveal  that  their  problems  would  have  been  avoided  or  strongly 
reduced  with  an  explicit  early  concern  for  identifying  and  resolving  high-risk  elements. 
[Ref.  3]  New  concepts  firom  behavioral  decision  theory  have  sparked  research  into  human 
decision  making. 

Behavioral  decision  theory  concludes  that  people  make  choices  using  only  a  few 
sources  of  information  processed  with  simple  rules  of  thumb.  Morecroft  modeled  the 
idea  that  only  a  few  information  flows  actually  penetrate  to  the  heart  of  the  decision 
function,  passing  through  several  cognitive  and  organizational  filters,  where  they 
influence  the  choices  and  actions  of  the  individual.  The  influence  of  behavioral  decision 
theory  on  system  dynamics  can  be  seen  in  the  development  of  microworlds  or  models 
that  represent  organizations  as  decision  making/information  processing  systems  involving 
many  players,  with  multiple  (often  conflicting)  goals  and  limited  processing  capability. 
[Ref.  4] 

The  Systems  Dynamics  Model  (SDM)  of  Software  Project  Management  models 
the  dynamic  nature  of  software  project  development  [Ref.  5].  This  simulation-based 
model  has  been  used  to  conduct  micro-empirical  research  on  dynamic  decisions  made  by 
software  project  managers  [Ref.  6-11]. 
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B.  PURPOSE  OF  RESEARCH 


The  purpose  of  this  thesis  is  to  design  and  conduct  an  experimental  investigation 
into  the  effects  of  risk  on  software  project  management.  The  SDM  of  Software  Project 
Management  will  be  used  to  study  in  a  controlled  environment,  how  project  managers 
handle  risk  factors,  how  perceived  risk  affects  decision  making,  and  in  turn  project 
outcome  in  terms  of  final  cost  and  schedule. 

C.  SCOPE  OF  RESEARCH 

The  scope  of  this  research  includes  the  experimental  design,  development  of 
software  to  support  the  design,  preparation  of  documentation  and  instruction  sets  for  the 
participants,  tailoring  of  the  gaming  interface  to  include  risk  factors,  providing  additional 
report  capabilities,  execution,  and  performance  assessment  of  the  allocation  of  resources 
by  differing  group  project  managers.  Care  was  taken  in  the  preparation  of  additional 
report  capabilities  and  smoothing  of  the  instruction  sets  in  an  effort  to  prevent 
introducing  external  biases.  This  research  was  conducted  in  a  single  project 
environment. 

D.  LIMITATIONS 

Forty-one  graduate  students  at  the  Naval  Postgraduate  School  participated  in  the 
experiment  as  surrogates  for  software  project  managers.  These  students  were  in  their 
seventh  quarter  of  a  masters  program  in  Information  Technology  Management.  They 
have  completed  significant  course  work  and  posses  several  years  of  practical  managerial 
experience.  These  students  also  participated  in  a  similar  experimental  investigation  on 
the  effect  of  goals  on  dynamic  decision  making  as  part  of  a  software  engineering  course 
requirement. 
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E.  THESIS  ORGANIZATION 

Chapter  II  is  a  detailed  description  of  the  experimental  design  and  the 
methodology  used.  The  design  includes  preparing  the  gaming  interface,  the  software, 
the  documentation,  conducting  the  practice  experiment,  and  making  final  preparations. 

Chapter  III  describes  conducting  and  organizing  the  experiment,  including  the 
dependent  measures  to  be  used.  Chapter  IV  is  the  data  analyses  and  experimental 
results.  Specifically  this  chapter  contains  descriptive  statistics  from  the  three  groups  and 
discusses  the  findings.  Chapter  V  contains  the  conclusions  and  recommendations  for 
further  study. 
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n.  PREPARING  THE  GAME  INTERFACE 


A.  EXPERIMENTAL  DESIGN 

The  Systems  Dynamics  Model  of  Software  Development  is  a  role  playing 
computer  based  simulation  game  that  mimics  the  programming  phase  of  a  real  software 
development  project.  The  participants  assume  the  role  of  software  project  manager  and 
make  resource  allocation  decisions  to  complete  the  project  on  time  and  within  schedule. 
The  software  project  manager  makes  staff  allocation  decisions  including  the  total  number 
of  staff  and  the  percent  of  staff  allocated  to  quality  assurance.  The  project  managers  also 
provide  their  estimates  of  cost  and  schedule  throughout  the  project  at  each  of  the  40  day 
intervals. 

The  project  begins  with  a  core  team  of  four.  These  software  professionals 
provide  the  continuity  between  the  requirements/design  phase  and  the  programming 
phase.  The  project  managers  initially  receive  estimates  of  the  size  of  the  system  in 
delivered  source  instructions,  cost  of  the  programming  phase  in  person  days,  and 
duration  of  the  programming  phase  in  days.  Every  two  month  interval,  40  working  days, 
the  model  generates  status  information  on  the  projects’  progress.  At  the  end  of  the 
period  and  after  reviewing  these  reports  and  graphs,  the  project  manager  is  able  to  make 
adjustments  to  the  staffing  level  and  its  allocation. 

The  research  question  is  to  determine  the  effects  of  risk  in  terms  of  staff  turnover 
on  software  project  management.  The  41  students  were  randomly  assigned  to  three 
groups  [Ref.  12].  The  randomization  worksheet  is  contained  in  Appendix  P.  All  three 
groups  interacted  with  projA.dnx.  The  source  code  is  available  in  Appendix  J.  The 
three  groups  were  the  uncertainty  group,  the  risk  group,  and  the  certainty  group. 

B.  THE  THREE  GROUPS 

The  software  program  managers  of  the  uncertainty  group  (Al)  did  not  receive  any 
probability  information  about  staff  turnover.  The  risk  group  (A2)  managers  were  told 
that  historically  the  turnover  rate  averages  to  1 .5  people  lost  every  reporting  period.  The 
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certainty  group  (Bl)  managers  were  notified  in  advance  about  personnel  intending  to 
leave  the  project  during  the  next  40  day  period.  The  number  of  staff  lost  due  to  turnover 
experienced  in  a  period  was  determined  in  advance  and  designed  into  the  simulation  at 
the  onset.  The  project  was  created  using  data  collected  from  an  actual  NASA 
development  effort. 

C.  THE  SOFTWARE 

The  students  for  this  experiment  had  participated  in  an  experimental  investigation 
of  the  impact  of  goals  on  software  project  development  six  months  earlier.  First,  part 
of  the  feedback  from  that  experiment  included  a  request  to  capture  cumulative 
information  on  project  status  from  several  periods  and  make  it  available  to  the  project 
manager.  To  incorporate  this  change,  a  new  report,  the  Project  Cumulative  Report,  was 
created.  It  is  a  report  specification  file  that  captures  the  values  of  variables  in  different 
periods  and  displays  them  to  the  user.  This  file  is  written  in  Dynamo  Plus  and  is 
displayed  in  Appendix  A. 

Two  other  new  dynamo  report  specification  (.drs)  files  are  contained  in 
Appendices  B  and  C.  These  files  are  the  staff  loss  notices  for  the  project.  These  files 
were  created  to  display  staff  turnover  information  to  the  project  managers  of  the  three 
groups.  The  project  managers  for  the  uncertainty  and  risk  groups  used  the  project  A 
batch  control  file  while  the  managers  for  the  certainty  group  used  the  project  B  batch 
control  file. 

During  execution  of  the  batch  control  files,  the  Staff  Loss  Report  Specification 
and  the  Planned  Loss  Report  Specification  programs  are  called  and  allow  for  the 
information  contained  in  them  to  be  displayed.  A  sample  of  the  report  shown  to  the 
managers  of  the  certainty  group  is  contained  in  Appendix  D.  This  report  flashes  on  the 
screen  and  notifies  the  project  manager  of  personnel  leaving  within  the  next  40  days. 
For  the  participants  of  the  uncertainty  and  risk  groups  the  report  differs  in  that  it  flashes 
on  the  screen  the  total  number  of  personnel  lost  in  the  previous  period.  This  staff  loss 
notice  is  displayed  in  Appendix  F. 
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Figure  2-1  Number  of  Staff  Losses  Per  40  Day  Time  Period 


Figure  2-1  displays  the  number  of  people  lost  due  to  turnover  in  each  of  the  40 
day  periods  throughout  the  project.  For  example  at  time  120,  project  managers  of  the 
certainty  group  would  receive  a  staff  loss  notice  telling  them  that  2  people  intend  to  leave 
the  project  within  the  next  40  days.  The  same  is  not  true  for  managers  in  the  risk  and 
uncertainty  groups.  However  during  time  160  these  two  groups  would  be  notified  that 
the  project  lost  two  people  due  to  turnover. 

A  menu  capability  for  accessing  multiple  reports  and  graphs  was  developed  in  an 
earlier  research  effort  along  with  a  detailed  description  of  module  interaction  for  the 
simulation  [Ref.  13].  The  Project  Staffing  Report  was  modified  to  provide  additional 
information  for  this  project.  Two  output  variables  were  created  to  report  the  total  staff 
at  the  beginning  of  the  period  and  the  total  staff  hired  in  the  period.  This  information 
was  provided  to  the  project  manager  to  clarify  what  staffing  changes  had  occurred.  The 
report  includes  the  total  staff  size,  the  percent  of  workforce  experienced  as  of  a  particular 
day  in  the  programming  phase,  and  is  displayed  in  Appendix  E. 

Another  dynamo  report  specification  was  developed  for  this  experiment.  A 
progress.drs  file  was  created  to  flash  the  current  period  prior  to  any  loss  notices  being 
displayed.  This  progress  report  specification  is  contained  in  Appendix  G.  The  report 
specifications  for  the  graphs  were  also  changed.  These  changes  are  summarized  in 
Appendix  O.  Coding  was  added  to  the  batch  control  files  to  allow  these  reports  to  be 
displayed  to  the  user.  These  batch  control  files  are  contained  in  Appendices  H  and  I. 
Having  completed  the  software,  the  documentation  was  developed  to  provide  the  details 
of  the  experiment  to  the  users. 
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D.  THE  DOCUMENTATION 

A  written  description  of  the  simulation  interface,  the  menu,  the  reports,  and  the 
graphs  available  to  the  project  managers  is  contained  in  Appendix  E.  The  menu  allows 
the  project  manager  to  select  the  report  or  graph  to  be  viewed.  These  can  be  viewed 
repeatedly.  An  option  at  the  bottom  of  the  menu  allows  the  user  to  proceed  with  the 
simulation. 

The  first  report  is  the  Project  Status  Report.  This  report  shows  the  initial 
estimates  for  the  project,  updated  estimates  entered  by  the  project  manager,  and  reported 
progress  on  the  project.  This  information  is  also  contained  in  the  Project  Cumulative 
Report.  This  report  aggregates  the  information  from  the  start  of  the  project  to  the 
current  period.  When  the  percent  DSI  reaches  100,  the  simulation  is  complete. 

The  Staffing  Report  provides  the  current  total  staff  size  and  the  allocation  of  staff 
between  programming  and  quality  assurance.  The  report  reflects  any  changes  in  the 
staffing  level  hired  or  lost  and  provides  the  program  manager  with  the  percent  of 
workforce  that  is  experienced.  A  trained  staff  member  is  twice  as  productive  as  a  new 
hire.  A  Defect  Report  details  the  total  defects  detected  and  the  defect  density  for  the 
current  period  and  for  the  last  40  days. 

Additional  documentation  was  provided.  Each  project  manager  received  an 
instruction  set.  Appendices  K-M.  The  group  instruction  sets  were  different.  Duplicate 
information  includes  the  rules  of  the  game,  instructions  for  starting  the  system,  and  initial 
project  estimates. 

Project  managers  were  told  that  for  modest  additions  in  staffing,  the  average 
hiring  delay  is  40  days.  Requests  for  a  large  number  of  additional  staff  will  cause  longer 
delays  and  these  new  hires  must  be  trained  and  assimilated.  The  assimilation  period  is 
typically  80  days.  Project  managers  were  also  given  information  about  the  possibility 
of  losing  people  due  to  turnover.  Lastly,  they  were  given  a  goal  to  minimize  both  cost 
and  schedule. 
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E.  TRIAL  EXPERIMENT 


The  purpose  of  the  trial  experiment  was  to  find  problems  with  either  the  software 
or  the  documentation.  Two  people  participated  in  the  trial  experiment.  These  were  the 
same  people  designated  as  lab  attendants  in  the  actual  experiment.  This  was  an 
opportunity  to  gain  feedback  on  the  experiments’  design.  Neither  student  experienced 
any  difficulty  in  the  trial  run. 

F.  FINAL  PREPARATIONS 

Two  labs  were  reserved  for  conducting  the  experiment.  Each  student  received 
an  envelope  containing  a  description  of  the  simulation  interface,  an  instruction  set,  a 
seating  chart,  and  a  disk.  The  disk  contained  the  files  for  running  the  experiment. 

All  copies  of  the  documentation  and  the  files  were  made  corresponding  to  the 
random  assignment  of  personnel  into  the  three  groups  conducted  earlier.  The 
randomization  worksheet  is  contained  in  Appendix  P.  The  terminals  in  the  labs  were 
checked  prior  to  assigning  personnel.  Signs  were  posted  on  the  labs  during  the 
experiment  to  prevent  other  students  from  entering.  The  remaining  task  was  to  assemble 
the  envelope  contents. 
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m.  CONDUCTING  THE  EXPERIMENT 


A.  TASKS  AND  PROJECT  CHARACTERISTICS 

The  students  for  the  experiment  received  a  40  minute  briefing  on  the 
documentation  for  the  experiment  and  a  review  of  the  terminology  present  in  the  reports. 
They  proceeded  to  the  labs  to  conduct  a  practice  experiment.  Each  student  was  given 
a  folder  containing  a  description  of  the  simulation  interface,  an  instruction  set,  a  seating 
chart,  and  a  disk.  The  students  were  instructed  that  their  level  of  effort  on  the  simulation 
would  be  reflected  in  their  class  participation  grade. 

The  practice  instruction  set  is  displayed  in  Appendix  N.  Seating  charts  were 
developed  and  were  the  same  for  both  the  practice  and  the  actual  experiment.  The  goal 
for  the  practice  experiment  was  for  the  students  to  familiarize  themselves  with  the 
simulation  environment.  The  inial  estimates  for  the  practice  project  remained  constant 
and  no  personnel  turnovers  occurred. 

The  instruction  set  for  the  practice  experiment  was  similar  to  that  of  the  other 
instruction  sets  except  that  it  lacked  any  information  on  the  project  risk,  that  of  losing 
people  due  to  turnover.  The  students  conducted  the  practice  experiment  in  30  minutes. 
Each  student  had  the  opportunity  to  make  staffing  allocation  decisions,  review  reports 
and  graphs,  and  ask  questions.  The  lab  attendants  received  a  15  minute  briefing  to 
ensure  questions  asked  were  answered  consistently.  The  designer  frequently  moved 
between  the  labs  during  the  practice  experiment. 

B.  THE  EXPERIMENTAL  SUBJECTS 

Project  managers  for  this  experiment  were  graduate  students  in  their  seventh 
quarter  of  an  eight  quarter  program  in  Information  Technology  Management  at  the  Naval 
Postgraduate  School.  They  have  taken  courses  in  software  engineering,  participated  in 
a  similar  experiment  six  months  earlier,  and  have  practical  managerial  experience.  These 
students  participated  in  the  actual  experiment  two  days  after  conducting  the  practice 
experiment. 
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Before  proceeding  to  the  labs  to  conduct  the  actual  experiment,  the  students 
received  a  ten  minute  briefing  on  project  risk.  Mentioned  were  the  primary  sources  of 
risk  including  personnel  shortfalls,  unrealistic  cost/ schedule,  and  changing  requirements. 

In  the  actual  experiment,  the  project  is  originally  underestimated.  The  project 
grows  from  the  original  estimate  of  42,000  DSI  to  64,000  DSI.  Students  are  briefed  that 
the  simulation  ends  when  the  reported  percent  DSI  complete  reaches  100. 

C.  DEPENDENT  MEASURES 

At  project  completion  ten  performance  variables  are  captured.  These  variables 
are  dependent  upon  the  decisions  made  by  the  project  manager  throughout  the 
experiment.  An  explanation  of  these  performance  variables  can  be  found  in  Appendix 
Q.  Three  of  these  performance  variables  are  final  cost,  final  cumulative  time,  and  final 
errors  remaining  undetected.  These  variables  are  compared  to  determine  differing  or 
similar  project  outcomes  between  the  three  groups;  uncertainty,  risk,  and  certainty. 

Final  cost  is  measured  in  person  days  and  final  cumulative  time  is  measured  in 
days.  Final  errors  remaining  undetected  is  a  measure  used  to  determine  the  quality  of 
the  software.  These  three  performance  variables  are  compared  as  part  of  the  data 
analysis  in  Chapter  IV. 
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IV.  EXPERIMENTAL  RESULTS  AND  ANALYSES 


A.  MODEL  OF  ANALYSIS 

Several  sets  of  data  were  captured  during  the  simulation.  These  data  include 
performance  data,  a  measure  of  project  outcome;  process  data,  a  measure  of  decisions 
made  over  time;  and  demographic  data.  The  demographic  data  was  obtained  through  the 
use  of  a  questionnaire.  A  questionnaire  was  completed  by  each  student  and  a  sample  is 
contained  in  Appendix  R. 

The  analysis  of  the  data  was  conducted  using  the  Statistical  Analysis  System 
(SAS)  software.  Procedure  Means,  and  the  Procedure  General  Linear  Models  (GLM). 
The  GLM  Procedure  was  used  for  multivariate  analyses.  The  Correlation  Procedure  was 
used  to  determine  correlation  between  independent  and  dependent  variables. 

B.  PERFORMANCE  DATA 


Final  cost,  final  schedule,  and  final  errors  are  the  three  dependent  measures  used 
to  evaluate  performance  differences  among  the  three  groups.  Figure  4-1  shows  means 


Group 

FNCOST,  Mean 

and  (Stnd  Dev) 

FNSKED,  Mean 

and  (Stnd  Dev) 

FNERR,  Mean 

and  (Stnd  Dev) 

Uncertainty  (Al) 

3333.66 

339.15 

13414.73 

(733.04) 

(54.9) 

(10470.29) 

Risk  (A2) 

2941.76 

310.21 

14654.44 

(523.73) 

(43.54) 

(9912.12) 

Certainty  (Bl) 

2667.01 

274.64 

11559.47 

(425.91) 

(47.49) 

(8144.78) 

Figure  4-1  Performance  Means  and  Standard  Deviations  for  the  Groups 
and  standard  deviations  for  the  three  groups  for  the  three  variables  mentioned.  The 
certainty  group  had  the  lowest  final  cost,  final  schedule,  and  errors  remaining. 
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The  subjects  of  the  certainty  group  were  given  advance  notice  of  staff  losses  to 
occur  during  the  next  40  day  period.  The  group  with  the  most  risk,  the  uncertainty 
group,  had  the  highest  mean  final  cost  and  schedule.  The  risk  group  participants,  given 
the  probability  of  staff  losses  to  occur  during  the  next  40  day  period,  had  the  next  highest 
final  cost  and  schedule.  The  results  indicate  that  the  information  received  by  the  groups 
pertaining  to  staff  turnover  significantly  influenced  project  outcome  in  terms  of  final  cost 
and  schedule. 

The  GLM  Procedure  was  used  for  comparison  of  the  groups’  performance  to 
determine  if  there  were  significant  differences  between  the  groups.  For  final  cost,  the 
GLM  yielded  a  p  value  of  0.0187.  This  rejects  the  null  hypothesis  of  no  differences 
between  the  groups  in  terms  of  final  cost.  This  result  indicates  that  for  final  cost  there 
were  significant  differences  between  the  three  experimental  groups. 

For  final  schedule  the  GLM  produced  a  p  value  of  0.0066.  Again,  the  null 
hypothesis  is  rejected  and  this  result  indicates  that  there  were  significant  differences 
between  the  three  groups  in  terms  of  schedule.  The  GLM  Procedure  for  final  errors 
revealed  a  p  value  of  0.7182.  The  null  hypothesis  is  accepted  that  there  was  no 
significant  difference  between  the  three  groups  in  terms  of  final  errors. 

C.  PROCESS  DATA 

The  subjects  made  four  decisions  in  each  period.  At  each  40  day  interval  the 
project  managers  selected  their  total  staff,  percentage  of  staff  allocated  to  quality 
assurance,  and  estimates  of  the  projects’  final  cost  and  schedule.  The  process  data  was 
analyzed  to  compare  group  means  at  each  40  day  interval.  In  graphing  the  group  means 
for  the  process  data  obtained,  the  last  interval  used  is  day  200.  This  is  the  last  period 
in  which  all  participants  were  still  making  decisions  and  had  not  completed  the  project. 
An  analysis  using  the  SAS  GLM  procedure  was  conducted  to  first  determine  if  there  was 
a  period  effect,  second  to  determine  any  time  effect  between  the  different  risk  groups, 
and  thirdly  to  determine  if  there  was  significant  difference  between  subjects  of  the  three 
groups. 
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Figure  4-2  Mean  Total  Staff  Requested  by  Group 

1.  Total  Staff 

Figure  4-2  is  a  graph  of  the  group  means  for  the  total  staff  requested  by  each 
group  at  each  40  day  interval.  The  graph  reveals  that  for  total  staff  the  uncertainty  group 
and  the  risk  group  made  similar  decisions.  These  project  managers  received  notice  of 
a  staff  turnover  after  it  had  occurred.  The  first  staff  loss  occurred  at  day  40. 

The  decisions  made  by  the  project  managers  of  the  certainty  group  are  different. 
These  project  managers  were  notified  at  day  40  that  three  people  intended  to  leave  during 
the  next  40  day  period  due  to  turnover.  It  can  be  seen  that  the  certainty  group  staff 
decisions’  increase  and  decrease  earlier  than  the  other  groups. 

The  analysis  for  a  period  effect  yielded  a  p  value  of  0.0001 .  This  allows  the  null 
hypothesis  of  no  period  effect  to  be  rejected.  There  is  a  period  effect.  The  test  for 
interaction  between  the  groups  yielded  a  p  value  of  0.0001.  Again,  the  null  hypothesis 
of  no  interaction  is  rejected.  The  test  for  between  subject  effects  yielded  a  p  value  of 
0.1925.  The  null  hypothesis  is  accepted  that  the  subjects’  decisions  toward  staffing  are 
not  significantly  different. 
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Figure  4-3  Percent  of  Requested  Staff  Allocated  to  QA  by  Group 

2.  Quality  Assurance 

Above  is  Figure  4-3,  the  percent  of  staff  allocated  to  quality  assurance  by  group. 
This  graph  depicts  that  there  is  a  period  effect.  Both  the  uncertainty  group  and  the  risk 
group  had  their  percent  staff  allocated  to  quality  assurance  decline  while  the  certainty 
group  had  an  initial  increase  in  staff  assigned  to  quality  assurance.  This  can  be  explained 
by  a  shift  in  personnel  from  quality  assurance  to  programming  as  staff  turnovers 
occurred. 

The  test  for  a  period  effect  yielded  a  p  value  of  0.0001.  The  null  hypothesis  of 
no  period  effect  is  rejected.  The  test  for  interaction  between  groups  yielded  a  p  value 
of  0.0078.  The  null  hypothesis  of  no  interaction  is  rejected.  For  the  between  subjects 
effects  test,  the  p  value  was  0.7630.  The  null  hypothesis  of  no  significant  difference 
between  subjects  is  accepted. 
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Figure  4-4  Estimates  of  Project  Final  Cost  by  Group 

3.  Cost  Estimates 

The  project  mean  cost  estimates  by  group  are  shown  in  Figure  4-4.  All  three 
groups  had  cost  estimates  that  continually  increased.  This  can  be  explained  by  the 
growth  in  project  size  from  its  initial  estimate  of  42,000  DSI  to  64,000  DSI.  Again  the 
graph  shows  that  there  is  a  period  effect. 

The  test  for  a  period  effect  revealed  a  p  value  of  0.0001  indicating  that  there  is 
a  period  effect  and  the  null  hypothesis  is  rejected.  The  test  for  interaction  yielded  a  p 
value  of  0.1751.  The  null  hypothesis  of  no  interaction  is  accepted.  For  the  between 
subjects  effects  the  p  value  was  0.1219.  The  null  hypothesis  of  no  between  subjects 
effect  is  accepted. 
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Figure  4-5  Estimates  of  Project  Final  Schedule  by  Group 

4.  Schedule  Estimates 

Figure  4-5  represents  the  project  final  schedule  estimates  by  group.  The  graph 
depicts  a  period  effect.  All  three  groups  also  had  increasing  estimates  for  the  final 
schedule.  Again,  this  can  be  explained  by  the  fact  that  the  project  increased  in  size  from 
the  initial  estimates. 

With  a  p  value  of  0.0001,  the  null  hypothesis  of  no  period  effect  is  rejected.  The 
test  for  interaction  revealed  a  p  value  of  0.0857.  The  null  hypothesis  of  no  interaction 
is  accepted.  The  test  for  between  subjects  effects  yielded  a  p  value  of  0.0848.  The  null 
hypothesis  of  no  between  subjects  effect  is  accepted. 
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D.  QUESTIONNAIRE  AND  DEMOGRAPHIC  DATA 


At  project  completion  each  participant  filled  out  a  questionnaire.  The  final  section 
of  the  questionnaire  was  dedicated  to  demographics.  The  demographic  data  format  can 
be  found  in  Appendix  S  and  sample  data  for  all  the  subjects  is  in  Appendix  T. 


Group 

AGE 

CHRSWK 

WKEXP 

EDAGO 

Uncertainty 

34.9 

28.1 

14.3 

13.3 

Risk 

34.5 

15.8 

12.6 

10.8 

Certainty 

32.8 

20.6 

10.8 

9.4 

Figure  4-6  Group  Mean  Demographics 


Figure  4-6  represents  the  sample  profile  by  group.  CHRSWK  represents  the 
number  of  hours  spent  on  the  computer  per  week,  WKEXP  represents  the  years  of  work 
experience,  and  EDAGO  is  the  number  of  years  since  the  subject  completed 
undergraduate  education.  The  uncertainty  group  subjects  have  the  highest  mean  age, 
have  more  work  experience,  and  spend  the  most  hours  per  week  on  the  computer.  The 
risk  group  subjects  spend  the  least  amount  of  time  on  the  computer  per  week.  The 
certainty  group  subjects  are  the  youngest  with  the  least  amount  of  work  experience  and 
have  most  recently  completed  their  undergraduate  education. 
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V.  CONCLUSIONS 


A.  FINDINGS  AND  IMPLICATIONS 

The  results  of  this  experimental  investigation  into  the  effects  of  risk  on  dynamic 
decision  making  in  a  software  project  environment  reveal  that  the  presence  of  risk 
significantly  impacts  project  outcome.  The  uncertainty  group,  the  group  receiving  the 
least  information  about  staff  turnover,  had  a  higher  final  cost  and  schedule  at  project 
completion.  The  risk  group  had  the  next  highest  final  cost  and  schedule.  The  certainty 
group,  which  were  informed  about  staff  departures  prior  to  their  occurrence,  performed 
better  than  the  other  two  groups. 

The  analysis  of  the  process  data  which  was  concerned  with  the  mean  performance 
of  the  groups  over  time,  revealed  that  the  groups  perform  significantly  different.  This 
is  especially  visible  in  the  graphical  depictions  of  total  staffing  and  quality  assurance 
allocation  decisions. 

The  certainty  group  once  informed  that  a  staff  loss  was  to  occur,  padded  the 
staffing  level  in  anticipation  of  the  loss  while  the  other  two  groups  responded  with 
additional  hires  immediately  following  the  loss.  This  perceived  risk  had  an  impact  on 
their  decision  making.  In  addition  the  risk  group  subjects  shifted  their  staffing  resources 
from  quality  assurance  to  programming  following  the  initial  loss  of  personnel. 

This  research  effort  provides  empirical  findings  that  support  the  assessment  and 
management  of  risk  as  significant  factors  in  achieving  successful  project  outcome.  The 
greater  the  risk  the  greater  the  cost  and  schedule  overrun.  Additionally,  this  research 
effort  seeks  to  provide  impetus  toward  investigation  of  other  human  behavioral  decision 
making  characteristics  found  in  the  software  project  development  domain. 
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B.  FURTHER  RESEARCH 


One  area  with  potential  for  further  research  is  to  investigate  the  impact  of  risk  on 
team  decision  making.  This  experiment  could  be  repeated  with  teams  managing  the 
project  rather  than  single  individuals.  This  would  provide  insight  into  team  management 
of  risk  and  the  communication  required.  It  is  likely  that  that  the  groups  would  identify 
and  deal  with  risk  differently.  Finally,  this  research  could  be  duplicated  in  a  multi¬ 
project  environment. 
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APPENDIX  A:  PROJECT  CUMULATIVE  REPORT  SPECIFICATION 


report 

time  =  maxtime, 

F0RMAT="5<" 

••>>>>>>>>>>>>>>>>>>>  PROJECT  CUMULATIVE  REPORT 
<<<<<<<<<<<<<<<<<<<<<<<<<<"; 

Format="5<,43<" 

"UPDATED  ESTIMATES", "REPORTED  PROGRESS"; 

Format="5  <  ,13  <  ,20<  ,26<  ,31  <  ,43  <  ,49  <  ,58  <  ,72  > ," 

"TIME" , "SIZE" ,  "COST" ,  "DUR" , "TIMREM" , "  %DSI" ,  "TOT  DSI" ,  "PD 
EXP’D","PROD"; 

FOR  TIME  =  40  TO  MAXTIME  BY  40  DO 
Format="2<,10<,17<,22<,30<,40<,49<,59<,72>", 

PICTURE  ="ZZZ  ZZ9V" 

TIME,PJBSZT,JBSZMD,SCHCDT,TIMERM,PRCMPL,CMDSI,CUMMD,RPPROD 

END 


"PRESS  <  ENTER  >  TO  RETURN  TO  THE  MENU" 
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APPENDIX  B:  STAFF  LOSS  REPORT  SPECIFICATION 


report 

time = maxtime, 

if  maxtime  <41  then 
FORMAT=''15<" 

ft  5|c  3|c  *  Jlc  ♦  ♦♦  :|e  :|c  5|e  5|«  ;|c  *  jjc  3|c  3|e  :|e  ♦  :|c  :tc  :)c  :|c  5|e  3|e  ♦♦  ♦***♦*♦**♦*♦**♦♦**♦*♦"  • 

> 

FORMAT="15<,67<" 

FORMAT= "  15  <  ,28  <  ,67  < " 

"Press  < ENTER >  to  continue.","*"; 
FORMAT="15<,67<" 

FORMAT="15<" 

end 

if  maxtime  >41  then 
if  maxtime  <81  then 
FORMAT="15<" 

II  :|c  5|e  :|e  3|e  **  a(e  :jc  3i<  5K  3(c  s(c  3lc  :jc  :|c  *  Jjc  ***♦♦  5}c  ♦♦***♦♦***♦*  5lc  ate  *********  • 

5 

FORMAT ="  15  <, 67  <" 

listen  listen. 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*","!!  STAFF  LOSS  NOTICE  !!","*"; 

FORMAT ="  15  <, 67  <" 

listen  listen. 

FOmAT="15  <  ,29<  ,42<  ,48<  ,67<  ",PICTURE="Z,ZZ9V" 
"*","[Current  TIME  =",TM,"DAYS]","*"; 

FORMAT ="  15  <, 67  <" 

listen  listen. 

FORMAT="15  <  ,21  <  ,67< " 

"During  the  last  40  day  Period,  the  project","*"; 

FORMAT = "  15  <  ,21  <  ,22  <  ,28  <  ,67  < " 

"*", "lost" ,WFLOSA, "people  due  to  turnover.","*"; 

FORMAT ="  15  <, 67  <" 

listen  listen. 
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FORMAT ="  15  <, 67  <" 

FORMAT = "  15  <  ,28  <  ,67  < " 

"Press  < ENTER >  to  continue.","*"; 

FORMAT ="  15  <, 67  <" 

FORMAT="15<" 

.tile****#***********************************************"; 

end 

end 

if  maxtime  >81  then 
if  maxtime  <  121  then 
FORMAT="15<" 

n;^:^^^***************************************************”; 
FORMAT ="  15  <, 67  <" 

li*tt  iijicft. 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*", "Press  < ENTER >  to  continue.","*"; 

FORMAT ="  15  <, 67  <" 

FORMAT ="  15  <" 

"♦♦♦sit**********************************************''***"; 

end 

end 

if  maxtime  >  121  then 
if  maxtime  <401  then 
FORMAT="15<" 

»*****************************************************"; 

FORMAT="15<,67<" 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*","!!  STAFF  LOSS  NOTICE 
FORMAT ="  15  <, 67  <" 

iialcit 

FORMAT= "  15  <  ,29  <  ,42  <  ,48  <  ,67  <  ", PICTURE ="Z,ZZ9V" 
"*", "Current  TIME  =",TM,"DAYS","*"; 
FORMAT="15<,67<" 

Hat:". 

FORMAT="15  <  ,21  <  ,67  < " 

"*", "During  the  last  40  day  Period,  the  project","*"; 
FORMAT="15  <  ,21  <  ,22<  ,28  <  ,67  <  " 
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"lost" ,WFLOSA, "people  due  to  turnover.","*"; 

FORMAT ="  15  <, 67  <" 

FORMAT="15<,67<" 

itjfcii  Mslei!, 

FORMAT= "  15  <  ,28  <  ,67  <  " 

"Press  <ENTER>  to  continue.","*"; 
FORMAT="15<,67<" 

FORMAT="15<" 

end 

end 

if  maxtime  >401  then 
if  maxtime<441  then 

FORMAT="15<" 

«:lc5lC9|cs(c:|6*5ic^5|esf:9le:lc:|e:ic:|e3(cs!e*:|c**:(c:ic*:|c:(c*:lc:|c:lc:jc:|c3lc*s|e3le*3lc3le***3lc5lc5H9!e*****5|«5|«”  j 

FORMAT="15<,67<" 

iiaieii 

FORMAT= "  15  <  ,28  <  ,67  < " 

"*", "Press  <ENTER>  to  continue.","*"; 
FORMAT="15<,67<" 

FORMAT="15<" 

9 

end 

end 

if  maxtime  >441  then 
FORMAT="15<" 

»:^4(:(e:|c:fe:|c:te9|e9|eHe3ic:iealc9|e3)c9ic:)e:ie:|c:|e9|C9{e^e)je:t(:|<:lc9te9ie9i<:*9|e9(e:le9|c:fe9|C9K3H)|ea)e3(e:|c3|e9)c:(e:)C)|c9ic9i«9|catc3)(*'  • 

9 

FORMAT ="  15  <, 67  <" 

FORMAT= "  15  <  ,28  <  ,67  <  " 

"*","!!  STAFF  LOSS  NOTICE  !!","*"; 

FORMAT="15<,67<" 

Illicit  llsfc«. 

FORMAT= "  15  <  ,29  <  ,42  <  ,48  <  ,67  <  ",PICTURE= "Z,ZZ9V" 
"*", "Current  TIME  =",TM,"DAYS","*"; 
FORMAT="15<,67<" 

«*ti  ftsieti. 

9  9 
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FORMAT = "  15  <  ,2 1  <  ,67  < " 

"During  the  last  40  day  Period,  the  project","*"; 
FORMAT = "  15  <  ,2 1  <  ,22  <  ,28  <  ,67  <  " 

"*", "lost" ,WFLOS A, "people  due  to  turnover.","*"; 
FORMAT ="  15  <, 67  <" 

FORMAT ="  15  <, 67  <" 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*", "Press  < ENTER >  to  continue.","*"; 
FORMAT ="  15  <, 67  <" 

FOmAT="15<" 

end 

if  maxtime  >481  then 
FORMAT ="  15  <" 

FORMAT ="  15  <, 67  <" 

II ii:jc*»- 

FOmAT= "  15  <  ,28  <  ,67  < " 

"*", "Press  < ENTER >  to  continue.","*"; 
FORMAT ="  15  <, 67  <" 

M:jcit  ii*i». 

FOmAT="15<" 

end 
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APPENDIX  C:  PLANNED  LOSS  REPORT  SPECIFICATION 


report 

time = maxtime, 

if  maxtime  <41  then 
F0RMAT="15<" 

1 1  j|e  5!c  sit  3|c  5|6  5ic  *  5|e  Jje  ♦♦***  3|c  3|e  j|c  *  sje  ♦****♦  alfi  ****♦»• . 

FORMAT="15<,67<" 

tt:|eu  tiaieii. 

FOmAT= "  15  <  ,28  <  ,67  < " 

STAFF  LOSS  NOTICE 
FORMAT="15<,67<" 

FORMAT= "  15  <  ,29  <  ,42  <  ,48  <  ,67  < "  ,PICTURE= ’'Z,ZZ9V" 

"  "  [Current  TIME  = "  ,TM,  "DAYS] 

FORMAT="15<,67<" 

11*11  «*«. 

FORMAT= "  15  <  ,21  <  ,41  <  ,47  <  ,67  < " 

"*","We  received  notice  from", WFLOSB, "people  that","*"; 
FORMAT= "  15  <  ,21  <  ,67  < " 

"*","they  intend  to  leave  the  project","*"; 

FORMAT= "  15  <  ,21  <  ,67  < " 

"*", "within  the  next  40  days.","*"; 

FORMAT="15<,67<" 

«*»»  lt*M. 

FORMAT="15<,67<" 

H*ll  lljjcif. 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*", "Press  < ENTER >  to  continue.","*"; 

FORMAT ="  15  <, 67  <" 

lf*«  «*«, 

FORMAT="15<" 

end 

if  maxtime  >41  then 
if  maxtime  <81  then 
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FORMAT="15<" 

FORMAT="15<,67<’' 

Majeii  ((9|ctt. 

FORMAT= "  15  <  ,28  <  ,67  < " 

"Press  <ENTER>  to  continue.","*"; 
FORMAT="15<,67<" 

FORMAT ="  15  <" 

II*****************************************************"- 

end 

end 

if  maxtime  >81  then 
if  maxtime  <361  then 
FORMAT="15<" 

FORMAT="15<,67<" 

M:IC«  «♦«. 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*","!!  STAFF  LOSS  NOTICE  !!","*"; 

FORMAT ="  15  <, 67  <" 

FORMAT = "  15  <  ,29  <  ,42  <  ,48  <  ,67  < "  ,PICTURE=  "Z,ZZ9V" 
"*", "[Current  TIME  =",TM,"DAYS]","*"; 

FORMAT ="  15  <, 67  <" 

FOmAT= "  15  <  ,21  <  ,41  <  ,47  <  ,67  < " 

"*","We  received  notice  from", WFLOSB, "people  that","*"; 
FORMAT = "  15  <  ,2 1  <  ,67  < " 

"*","they  intend  to  leave  the  project","*"; 

FORMAT = "  15  <  ,21  <  ,67  < " 

"*", "within  the  next  40  days.","*"; 

FORMAT ="  15  <, 67  <" 

i(9|eH  lijieM. 

FORMAT ="  15  <, 67  <” 

II  ♦tf. 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*", "Press  < ENTER >  to  continue.","*"; 

FORMAT ="  15  <, 67  <" 

ii9|ei*  ii9|cii. 

FO]mAT="15<" 

II*****************************************************"  I 
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end 

end 

if  maxtime  >  361  then 
if  maxtime  <401  then 
FORMAT="15<" 

FORMAT="15<,67<" 

II  iijjeii* 

FORMAT= "  15  <  ,28  <  ,67  < " 

"Press  <ENTER>  to  continue.","*"; 
FORMAT="15<,67<" 

ii:|cti  II ^11. 

FORMAT="15<" 

«*♦♦*♦*♦♦♦#**♦**♦****♦♦♦♦******♦*♦*******♦***♦***♦****" 

end 

end 

if  maxtime  >401  then 
if  maxtime<441  then 
FORMAT="15<" 

ii5|e****^**3jcs!c*:|c3|c3|c:|c:(c3|c9|s3|C5*e***sJJ**3i«**********3lc3lc3|e*a(e*3|e*********" 

FORMAT="15<,67<" 

listen  listen. 

F0IUV1AT= "  15  <  ,28  <  ,67  < " 

"*","!!  STAFF  LOSS  NOTICE  !!","*"; 

FORMAT ="  15  <, 67  <" 

114:11  listen. 

FOmAT= "  15  <  ,29  <  ,42  <  ,48  <  ,67  < "  ,PICTURE=  "Z,ZZ9V" 
"*", "[Current  TIME  =",TM,"DAYS]","*"; 

FORMAT ="  15  <, 67  <" 

listen  listen. 

FORMAT= "  15  <  ,21  <  ,41  <  ,47  <  ,67  < " 

"♦"  "We  received  notice  from" ,WFLOSB, "people  that","*"; 
FORMAT= "  15  <  ,21  <  ,67  < " 

"*","they  intend  to  leave  the  project","*"; 

FORMAT= "  15  <  ,21  <  ,67  < " 

"*", "within  the  next  40  days.","*"; 

FORMAT="15<,67<" 

listen  listen. 

FORMAT="15<,67<" 

listen  listen. 

FORMAT= "  15  <  ,28  <  ,67  < " 
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"Press  < ENTER >  to  continue.","*"; 

FORMAT = "15  <, 67  <" 

II3|CI»  •»**». 

FOmAT=’T5<" 

«***K!»**»***#***»*»*****#**»*****>I'»***»***»*******»***" 

end 

end 

if  maxtime  >441  then 
FORMAT='T5<" 

II  ♦#♦♦♦*♦*♦»****»**♦*♦♦*♦**♦♦*****♦♦********♦**********" 

FORMAT = "15  <, 67  <" 

FORMAT = "  15  <  ,28  <  ,67  < " 

"*", "Press  <ENTER>  to  continue.","*"; 

FORMAT ="  15  <, 67  <" 

II  ll)|Cll. 

FORMAT ="  15  <" 
end 
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APPENDIX  D:  PLANNED  LOSS  OUTPUT 


* 

*  1 1  STAFF  LOSS  NOTICE  I  1 

* 

*  [Current  TIME  =120  DAYS] 

* 

*  We  received  notice  from  2  people  that 

*  they  intend  to  leave  the  project 

*  within  the  next  40  days. 

* 

* 

*  Press  <ENTER>  to  continue. 

* 


* 

* 

★ 

* 

* 

* 

★ 

* 

* 

* 

* 
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APPENDIX  E:  DESCRIPTION  OF  THE  SINUIiATION  INTERFACE 


REPORTS  AND  GRAPHS  MENU: 

After  every  40-day  simulation  period,  you  will  immediately  get  the 
Reports  and  Graphs  Menu  shown  below.  All  of  the  reports  and  graphs 
concerning  your  project's  progress  are  available  from  this  menu.  You 
may  select  any  of  them  by  pressing  their  corresponding  number. 


REPORTS  AND  GRAPHS  MENU  1 - j 

REPORTS : 

B 

PROJECT  SIZE  &  STATUS  REPORT 

2 

STAFFING  REPORT 

3 

DEFECT  REPORT 

4 

CUMULATIVE  REPORT 

GRAPHS: 

5 

PROJECT  SIZE  &  STATUS  GRAPH 

6 

STAFFING  GRAPH 

■ 

DEFECT  GRAPH 

PRESS 

P 

TO  PROCEED  TO  ENTER  DECISIONS  FOR  THE  NEXT  40  DAYS 

After  viewing  the  pertinent  information  (you  may  view  any  report  or  graph  more  than 
once),  use  the  "P"  selection  to  proceed  to  enter  your  decisions  for  the  next  40  day  simulation 
period. 
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Report  1  (PROJECT  STATUS  REPORT)  A  sample  report  is  pictured  below: 


PROJECT  STATUS  REPORT 


AT  TIME  = 


120  DAYS 


INITIAL  ESTIMATES:  (These  will  not  change  throughout  the  project) 

System  Size  20,000  DSI 

Programming  Cost  1.400  Person  Days 

Programming  Phase  Duration  (start-end)  350  Days 


UPDATED  ESTIMATES 

New  Est  of  System  Size 

due  to  Changes  in  Requirements  20,000 

Your  Last  Est  of  Programming  Phase  Cost  1,567 

Your  Last  Est  of  Prog  Phase  Duration  (start-end) 353 
Time  Remaining  1^^ 

REPORTED  PROGRESS 

%  DSI  Reported  Complete  63.33 

Total  DSI  Reported  Complete  to  Date  12,665 

Total  Person  Days  Expended  to  Date  817 

Reported  Productivity  16 


DSI 

Person  Days 

Days 

Days 

Percent 

DSI 

Person  Days 
DSI/Person  Day 


PRESS  <ENTER>  TO  RETURN  TO  THE  MENU 


This  report  contains  Project  Status  information  as  of  a  particular  day  in  the 
programming  phase.  The  report  is  divided  into  3  sections.  The  top  section  shows  the 
INITIAL  ESTIMATES  provided  to  your  customer.  This  information  will  not  change 
throughout  the  project. 

The  middle  portion  is  the  UPDATED  ESTIMATES  section.  The  Updated  Est  of 
System  Size  can  change  (increase  or  decrease)  to  reflect  the  addition  or  deletion  of 
requirements.  The  entries  of  Your  Last  Est  of  Programming  Hiase  Cost  and  Your  Last 
Est  of  Prog  Hiase  Duration  (start-end)  would  reflect  any  change  in  cost  and  duration  that 
you  feel  you  need  to  make.  The  Time  Remaining  is  equal  to  your  current  estimate  of  total 
duration  minus  current  time. 

The  bottom  section  is  the  REPORTED  PROGRESS  section.  Remember  that  this  is 
"reported"  information  and  is  not  guaranteed  to  be  totally  accurate,  especially  early  in  the 
phase.  Reported  Productivity  is  simply  calculated  as  Total  DSI  Reported  Complete  to 
Date  divided  by  Total  Person  Days  Expended  to  Date. 

Your  Task  is  complete  when  the  %  DSI  Reported  Complete  is  100%. 
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Report  2  (STAFFING  LEVEL  REPORT)  A  sample  report  is  pictured  below: 


STAFFING  REPORT 
AT  TIME  =  160  DAYS 


STAFFING  ADDITIONS/LOSSES  LAST  40  DAY  PERIOD  ONLY 
Total  Staff  At  Beginning  of  Period 
Total  Staff  Hired  this  Period 
Total  Staff  Lost  this  Period 

Current  Total  Staff  Size 

STAFF  ALLOCATION 

Staff  Allocated  to  Programming 
Staff  Allocated  to  QA 

Current  Total  Staff  Size 

Percent  of  Workforce  that  is  Experienced 

PRESS  <ENTER>  TO  RETURN  TO  THE  MENU 


7.21 

People 

2.49 

People 

2.00 

People 

7.69 

People 

6.92 

People 

.77 

People 

7.69 

People 

43 

Percent 

This  report  contains  staffing  information  as  of  a  particular  day  in  the  programming 
phase.  The  Current  Total  Staff  Size  consists  of  your  total  staff  allocated  to  both 
programming  activities  and  QA  activities.  It  is  the  sum  of  Staff  Allocated  to 
Programming  and  Staff  Allocated  to  QA. 

The  Percent  of  Workforce  that  is  Experienced  is  also  shown  on  this  report.  This  is 
the  number  of  experienced  people  (i.e.  already  trained/assimilated)  divided  by  the  total  staff 
size  (which  is  the  sum  of  experienced  and  new  staff).  As  mentioned  above,  once  new  people 
are  hired,  they  go  through  an  assimilation/training  period.  This  is  the  time  needed  to  train  a 
new  employee  in  the  mechanics  of  the  project  and  bring  him/her  up  to  speed.  A  new 
employee  (i.e.  one  that  is  being  trained)  is  only  half  as  productive  as  an  experienced 
employee. 


37 


Report  3  (DEFECT  REPORT)  A  sample  report  is  pictured  below: 


DEFECT  REPORT 


CXJMULATIVE  STATUS  FROM  START  OF  PROJECT  TO  CURRENT  DAY  =>  200 


TOTAL  Person  Days  Expended  to  Date 
Programming  Person  Days  Expended 
QA  Person  Days  Expended  to  Date 

TOTAL  Defects  Detected 
TOTAL  KDSI  Completed 
Defect  Density 

- STATISTICS  FOR  THE  LAST  40 


817 

Person  Days 

to  Date 

735 

Person  Days 

82 

Person  Days 

137 

Defects 

12.67 

KDSI 

DAY  PERIOD 

10.9 

ONLY - 

Defects/KDSI 

QA  Person  Days  Expended  Last  40  Days 
Defects  Detected  Last  40  Days 
Defect  Density  Observed  Last  40  Days 


18  Person  Days 

38  Defects 

11.6  Defects/KDSI 


PRESS  <ENTER>  TO  RETURN  TO  THE  MENU 


This  report  recaps  the  TOTAL  Person  Days  Expended  to  Date  and  provides  a 
breakdown  of  the  number  of  person  days  expended  on  both  the  QA  and  programming 
activities. 

In  the  top  section,  this  report  gives  cumulative  defect  data  (i.e.  from  start  of 
programming  phase  to  current  time).  The  bottom  section  shows  data  for  the  last  40  day 
period  only. 

Historically,  the  Defect  Density  (i.e.  number  of  defects  detected  during  programming 
divided  by  the  number  of  KDSI  develop^)  has  ranged  from  5-20  Defects/KDSI. 

Comparing  the  aggregate  data  and  the  data  for  the  last  period  can  indicate  trends. 
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Report  4  (CUMULATIVE  REPORT)  A  sample  report  is  pictured  below: 


PROJECT  CUMULATIVE  REPORT 


UPDATED  ESTIMATES 


REPORTED  PROGRESS 


TIME 

SIZE 

COST 

DUR 

40 

20,000 

1,400 

350 

80 

20,000 

1,400 

350 

120 

20,000 

1,400 

350 

160 

20,000 

1,400 

350 

200 

20,000 

1,400 

350 

PRESS  <ENTER>  TO  RETURN 


TIMREM 

%DSI 

TOT  DSI 

310 

7 

1,434 

270 

15 

3,020 

230 

25 

5,092 

190 

38 

7,587 

150 

52 

10,483 

THE  MENU 


PD  EXP'D 
78 
199 
366 
550 
738 


PROD 

18 

15 

14 

14 

14 


This  report  contains  Cumulative  Project  Status  information  from  the  start  of  the 
project  to  the  current  period.  The  report  is  divided  into  2  sections. 

The  left  portion  is  the  UPDATED  ESTIMATES  section.  It  reflects  cumulative 
changes  in  the  following  project  estimates: 

SIZE  New  Estimate  of  System  Size  due  to  changes  in  Requirements 

(DSI) 

COST  Your  Last  Est  of  Programming  Phase  Cost  (Person  Days) 

DUR  Your  Last  Est  of  Prog  Phase  Duration  (start-end)  (Days) 

TIMREM  Time  Remaining  (Days) 

The  right  portion  is  the  REPORTED  PROGRESS  section.  Remember  that  this  is 
"reported"  information  and  is  not  guaranteed  to  be  totally  accurate,  especially  early  in  the 
phase.  It  reflects  cumulative  changes  in  the  following  project  estimates: 

%DSI  %DSI  Reported  Complete  (Percent) 

TOT  DSI  Total  DSI  Reported  Complete  to  Date  (DSI) 

PD  EXP’D  Total  Person  Days  Expended  to  Date  (Person  Days) 

PROD  Reported  Productivity  (DSI/Person  Day) 

Your  Task  is  complete  when  the  %  DSI  is  100%. 
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Graph  5  (PROJECT  STATUS  GRAPH) 

This  graph  shows  how  the  total  staff  level  and  the  estimates  of  system  size  and 
programming  cost  are  changing  over  time. 

Graph  6  (STAFFING  GRAPH) 

This  graph  shows  how  the  level  of  the  total  staff,  programming  staff,  and  QA  staff  is 
changing  over  time. 

Graph  7  (DEFECT  GRAPH) 

This  graph  shows  how  "QA  person  days  expended  per  period"  and  the  "number  of 
defects  detected  per  period"  are  changing  over  time. 
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APPENDIX  F:  STAFF  LOSS  OUTPUT 


! 1  STAFF  LOSS  NOTICE  ! 1 

Current  TIME  =  160  DAYS 

During  the  last  40  day  Period,  the  project 
lost  2  people  due  to  turnover. 

Press  <ENTER>  to  continue. 


* 

* 

* 

* 

★ 

★ 

* 

* 

* 

* 
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APPENDIX  G:  PROGRESS  REPORT  SPECIFICATION 


report 

t ime=max t ime , 
FORMAT*" 15<" 


FORMAT*" 15<, 67<" 

M  *  n  ^  M  *  11  . 

FORMAT="15<,21<,67<" 

"*","The  model  has  simulated  a  40  day  period.","*"; 
FORMAT="15<,67<" 

II  *  n  ^  II  *  II  . 

FORMAT*" 15< , 29< , 42< , 48< , 67<" , PICTURE*" Z , ZZ9V" 

[Current  TIME  =" ,TM, "DAYS] " , "*" ; 

FORMAT*" 15<,67<" 

I  *  w  I  *  J 

FORMAT*"15<,28<,67<" 

••*•1^ "Press  <ENTER>  to  continue.","*"; 

FORMAT* " 15< , 6 7< " 

II  *  II  ^ 

FORMAT="15<" 

M************************************************"*"****”; 
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APPENDIX  H:  BATCH  CONTROL  FILE  (PROJECTA) 

©echo  off 

rem  PROJA  initially  underestimated  project 
els 

rem  init.exe  requires  3  parameters  i,e.  [project, group, ins . set ] 

init  All 

graphics 

bat  /n  /p  /s 

ram 

smlt  PROJA  -go  =  -prs  =  -Is  -ns  -plm  16 

rep  PROJA*RSL  PROCESS. DRS  -outf  PROCESS. OUT  -t  >NUL 

rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESSS.OUT  -t  >NUL 


-top  dynex  PROJA  -in  PROJA. STT  -sc  -Is  -plm  16 
smlt  PROJA  -gm  =  -ns  -plm  16 


copy  process. out  process. old  >NUL 

rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESS. OUT  -t  >NUL 
rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESSS.OUT  >NUL 
rep  PROJA. RSL  INTERVAL. DRS  -outf  INTERVAL. OUT  -t  >NUL 
process 


call  -topi 

rep  PROJA. RSL  PERFORM. DRS  -outf  PERFORM. OUT  -t  >NUL 

perform 

rem  finish 

exit 


-topi  els 


-PROGREP  ****  VIEW  PROGRESS  ********************************* 
timestmp 

rep  PROJA  PROGRESS. DRS  -outf  PROGRESS. OUT  -t  -SC  -Is  -plm  16 
inkey 

capture  R5  >NUL 
els 

color  \1F 


-STAFLOSS  *****  VIEW  STAFFING  LOSS  REPORT  ******************** 
timestmp 

rep  PROJA  STAFLOSS. DRS  -outf  STAFLOSS. OUT  -t  -sc  -Is  -plm  16 
inkey 

capture  R6  >NUL 
els 

color  \1F 


-menu 

color  \1F 
els 

begtype 
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REPORTS  AND  GRAPHS  MENU 


\1EREP0RTS:\1F 

\1E  1  \1F 

\1E  2  \1F 

\1E  3  \1F 

\1E  4  \1F 
\1BGRAPHS:  \1F 

\1B  5  \1F 

\1B  6  \1F 

\1B  7  \1F 


PROJECT  SIZE  &  STATUS  \1EREP0RT\1F 

STAFFING  \1EREP0RT\1F 

DEFECT  \1EREP0RT\1F 

CUMULATIVE  \1EREP0RT\1F 

PROJECT  SIZE  &  STATUS  \1BGRAPH\1F 

STAFFING  \1BGRAPH\1F 

DEFECT  \1BGRAPH\1F 


PRESS \ ID  P  \1F  TO  \lDPROCEED\lF  TO  ENTER  DECISIONS  FOR  THE  NEXT  40  DAYS 


Choose  an  option:  (Do  NOT  hit  <ENTER>  after  selection!!!) 
end 


Istkeyl 

.  inkey 

%2  j 

type  %2 ; 

if 

%2 

= 

1 

goto 

-STATREP 

if 

%2 

2 

goto 

-STAFREP 

if 

%2 

= 

3 

goto 

-DEFREP 

if 

%2 

= 

4 

goto 

-CUMREP 

if 

%2 

5 

goto 

-STATPLOT 

if 

%2 

= 

6 

goto 

-STAFPLOT 

if 

%2 

= 

7 

goto 

-DEFPLOT 

if 

%2 

P 

goto 

-proceed 

if 

%2 

=r 

KEYOll 

return 

beep  goto  -menu 


-STATREP  ****  VIEW  PROJECT  STATUS  REPORT  ******************** 
timestmp 

rep  PROJA  STATUS. DRS  -outf  STATUS. OUT  -t  -sc  -Is  -plm  16 
inkey 

capture  R1  >NUL 
els 

color  \1F 
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r 


goto  -menu 


-STAFREP  ****  VIEW  STAFFING  REPORT  ******************** 
timestmp 

rep  PROJA  STAFFING. DRS  -outf  STAFFING. OUT  -t  -sc  -Is  -plm  16 
inkey 

capture  R2  >NUL 
els 

color  \1F 
goto  -menu 


-DEFREP  ****  VIEW  DEFECT  REPORT  ******************** 
timestmp 

rep  PROJA  DEF.DRS  -OUtf  DEF.OUT  -t  -SC  -Is  -plm  16 
inkey 

capture  R3  >NUL 
els 

color  \1F 
goto  -menu 

-CUMREP  ****  VIEW  PROJECT  CUMULATIVE  REPORT  ******************** 
timestmp 

rep  PROJA  CUM. DRS  -outf  CUM. OUT  -t  -sc  -Is  -plm  16 
inkey 

capture  R4  >NUL 
els 

color  \1F 
goto  -menu 


-STATPLOT  ****  VIEW  PROJECT  STATUS  PLOT  **** 
timestmp 
els 

color  \1F 
begtype 


******************************************************************************* 

* 

\1A  PROJECT  STATUS  VARIABLES  \1F 

******************************************************************************* 

THE  FOLLOWING  PROJECT  STATUS  VARIABLES  WILL  BE  PLOTTED: 
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TOTAL  STAFF . 

EST  SYSTEM  SIZE . 

EST  PROGRAMMING  COST  .  . 


TOTAL  STAFF  LEVEL 

CURRENT  ESTIMATE  OF  SYSTEM  SIZE  (KDSI) 

CURRENT  ESTIMATE  OF  PROGRAMMING  COST  (Person  Days) 


\1A 


AFTER  VIEWING  PLOT  PRESS  <ESC>  TO  RETURN  TO  THE  MENU  \1F 


\1A  PRESS  <ENTER>  TO  VIEW  PLOT  \1F 


end 

inkey 

els 

rep  PROJA  STATPLOT.DRS 
capture  G5  >NUL 
color  \1F 
els 

goto  -menu 


-STAFPLOT  ****  VIEW  GRAPHIC  STAFFING  PLOT  **** 
timestmp 
els 

color  \1F 
begtype 


******************************************************************************* 

* 

\1A  STAFFING  VARIABLES  \1F 

******************************************************************************* 

THE  FOLLOWING  STAFFING  VARIABLES  WILL  BE  PLOTTED: 


TOTAL  STAFF 
QA  STAFF.  . 
PROG  STAFF. 


TOTAL  STAFF  LEVEL 

NUMBER  OF  PERSONS  ALLOCATED  TO  QA 
NUMBER  OF  PERSONS  DOING  PROGRAMMING 
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\1A  AFTER  VIEWING  PLOT  PRESS  <ESC>  TO  CONTINUE  \1F 


\1A  PRESS  <ENTER>  TO  VIEW  PLOT  \1F 


end 

inkey 

els 

rep  PROJA  STAFPLOT.DRS 
capture  G6  >NUL 
color  \1F 
els 

goto  -menu 


-DEFPLOT  ****  VIEW  DEFECT  PLOT  **** 
timestmp 
els 

color  \1F 
begtype 


******************************************************************************* 

* 

\1A  DEFECT  VARIABLES  \1F 

******************************************************************************* 

THE  FOLLOWING  DEFECT  VARIABLES  WILL  BE  PLOTTED: 


QA  PERSON  DAYS  PER  PERIOD  .  .  .  .  QA  PERSON  DAYS  EXPENDED  PER  PERIOD 
DEFECTS  DETECTED  PER  PERIOD  .  .  .  DEFECTS  DETECTED  PER  PERIOD 


\1A  AFTER  VIEWING  PLOT  PRESS  <ESC>  TO  RETURN  TO  THE  MENU  \1F 


\1A  PRESS  <ENTER>  TO  VIEW  PLOT  \1F 
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END 


inkey 

els 

rep  PROJA  DEFPLOT.DRS 
capture  G7  >NUL 
color  \1F 
els 

goto  -menu 


-proceed  ****  PROCEED  WITH  NEXT  SIMULATION  ******************** 
cls 

color  \1F 
begtype 


************************************************* 
*  Press  <ENTER>  to  continue  * 

************************************************* 


end 

goto  -top 


-on . error- 

if  %R  >  82  if  %R  <  90  type  !!  Floating  Point  Error  !!  [goto  -Calc. 
Cls  beep  type  Unexpected  batch  file  error  %R  in  line  %L  j exit 
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APPENDIX  I:  BATCH  CONTROL  FILE  (PROJECTB) 


§echo  off 

rem  PROJA  initially  underestimated  project 
els 

rem  init.exe  requires  3  parameters  i.e. 

[pro j  ect , group , ins . set ] 

init  B  1  1 

graphics 

bat  /n  /p  /s 

ram 

smlt  PROJA  -go  =  -prs  =  -Is  -ns  -plm  16 

rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESS. OUT  -t  >NUL 

rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESSS.OUT  -t  >NUL 


-top  dynex  PROJA  -in  PROJA. STT  -sc  -Is  -plm  16 
smlt  PROJA  -gm  =  -ns  -plm  16 

copy  process. out  process. old  >NUL 

rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESS. OUT  -t  >NUL 
rep  PROJA. RSL  PROCESS. DRS  -outf  PROCESSS.OUT  >NUL 
rep  PROJA. RSL  INTERVAL. DRS  -outf  INTERVAL. OUT  -t  >NUL 
process 

call  -topi 

rep  PROJA. RSL  PERFORM. DRS  -outf  PERFORM. OUT  -t  >NUL 

perform 

rem  finish 

exit 

-topi  els 


-PROGREP  ****  VIEW  PROGRESS 
********************************* 
times tmp 

rep  PROJA  PROGRESS. DRS  -outf  PROGRESS. OUT  -t  -sc  -Is 
-plm  16 

inkey 

capture  R5  >NUL 
els 

color  \1F 


-STAFLOSS  *****  VIEW  STAFFING  LOSS  REPORT 
******************** 

timestmp 

rep  PROJA  PLANLOSS.DRS  -OUtf  PLANLOSS.OUT  -t  -SC  -Is 
-plm  16 
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inkey 

capture  R6  >NUL 
els 

color  \1F 


-menu 

color  \1F 
els 

begtype 


REPORTS  AND  GRAPHS  MENU 


\1EREP0RTS:\1F 

\1E  1  \1F  PROJECT  SIZE  &  STATUS  \1EREP0RT\1F 
\1E  2  \1F  STAFFING  \1EREP0RT\1F 
\1E  3  \1F  DEFECT  \1EREP0RT\1F 

\1E  4  \1F  CUMULATIVE  \1EREP0RT\1F 

\1BGRAPHS:  \1F  ^  ^ 

\1B  5  \1F  PROJECT  SIZE  &  STATUS  \1BGRAPH\1F 

\1B  6  \1F  STAFFING  \1BGRAPH\1F 

\1B  7  \1F  DEFECT  \1BGRAPH\1F 


PRESS \ ID  P  \1F  TO  \1DPR0CEED\1F  TO  ENTER  DECISIONS  FOR  THE  NEXT  40  DAYS 


Choose  an  option;  (Do  NOT  hit  <ENTER>  after  selection!!!)  ; 
end 


-Istkeyl 

.  inkey 

%2  j  type  %2; 

if 

%2 

= 

1 

goto  -STATREP 

if 

%2 

2 

goto  -STAFREP 

if 

%2 

= 

3 

goto  -DEFREP 

if 

%2 

= 

4 

goto  -CUMREP 

if 

%2 

= 

5 

goto  -STATPLOT 

if 

%2 

= 

6 

goto  -STAFPLOT 

if 

%2 

= 

7 

goto  -DEFPLOT 

if 

%2 

= 

P 

goto  -proceed 

if 

%2 

= 

KEYOll  return 

beep  1 

goto 

-menu 
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-STATREP  ****  VIEW  PROJECT  STATUS  REPORT  ******************** 
timestmp 

rep  PROJA  STATUS. DRS  -outf  STATUS. OUT  -t  -SC  -Is  -plm  16 
inkey 

capture  R1  >NUL 
els 

color  \1F 
goto  -menu 


-STAFREP  ****  VIEW  STAFFING  REPORT  ******************** 
timestmp 

rep  PROJA  STAFFING. DRS  -outf  STAFFING. OUT  -t  -sc  -Is  -plm  16 
inkey 

capture  R2  >NUL 
els 

color  \1F 
goto  -menu 


-DEFREP  ****  VIEW  DEFECT  REPORT  ******************** 
timestmp 

rep  PROJA  DEF.DRS  -outf  DEF.OUT  -t  -sc  -Is  -plm  16 
inkey 

capture  R3  >NUL 
els 

color  \1F 
goto  -menu 

-CUMREP  ****  VIEW  PROJECT  CUMULATIVE  REPORT  ******************** 
timestmp 

rep  PROJA  CUM. DRS  -outf  CUM. OUT  -t  -SC  -Is  -plm  16 
inkey 

capture  R4  >NUL 
els 

color  \1F 
goto  -menu 


-STATPLOT  ****  VIEW  PROJECT  STATUS  PLOT  **** 
timestmp 
els 

color  \1F 
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begtype 


******************************************************************************* 

ic 

\1A  PROJECT  STATUS  VARIABLES  \1F 

******************************************************************************* 

THE  FOLLOWING  PROJECT  STATUS  VARIABLES  WILL  BE  PLOTTED: 

TOTAL  STAFF . TOTAL  STAFF  LEVEL 

EST  SYSTEM  SIZE . CURRENT  ESTIMATE  OF  SYSTEM  SIZE  (KDSI) 

EST  PROGRAMMING  COST  .  .  .  CURRENT  ESTIMATE  OF  PROGRAMMING  COST  (Person  Days) 


AFTER  VIEWING  PLOT  PRESS  <ESC>  TO  RETURN  TO  THE  MENU  \1F 


PRESS  <ENTER>  TO  VIEW  PLOT  \1F 


inkey 

els 

rep  PROJA  STATPLOT.DRS 
capture  G5  >NUL 
color  \1F 
els 

goto  -menu 

-STAFPLOT  ****  VIEW  GRAPHIC  STAFFING  PLOT  **** 
timestmp 
els 

color  \1F 
begtype 


******************************************************************************’ 

•k 

\1A  STAFFING  VARIABLES  \1F 

******************************************************************************’ 


THE  FOLLOWING  STAFFING  VARIABLES  WILL  BE  PLOTTED: 
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TOTAL  STAFF  .  TOTAL  STAFF  LEVEL 

QA  STAFF . NUMBER  OF  PERSONS  ALLOCATED  TO  QA 

PROG  STAFF . NUMBER  OF  PERSONS  DOING  PROGRAMMING 


\1A  AFTER  VIEWING  PLOT  PRESS  <ESC>  TO  CONTINUE  \1F 


\1A  PRESS  <ENTER>  TO  VIEW  PLOT  \1F 


end 

inkey 

els 

rep  PROJA  STAFPLOT.DRS 
capture  G6  >NUL 
color  \1F 
els 

goto  -menu 


-DEFPLOT  ****  VIEW  DEFECT  PLOT  **** 
timestmp 
els 

color  \1F 
begtype 

******************************************************************************* 

* 

\1A  DEFECT  VARIABLES  \1F 

******************************************************************************* 

THE  FOLLOWING  DEFECT  VARIABLES  WILL  BE  PLOTTED: 


QA  PERSON  DAYS  PER  PERIOD  .  .  .  .  QA  PERSON  DAYS  EXPENDED  PER  PERIOD 
DEFECTS  DETECTED  PER  PERIOD  .  .  .  DEFECTS  DETECTED  PER  PERIOD 


\1A 


AFTER  VIEWING  PLOT  PRESS  <ESC>  TO  RETURN  TO  THE  MENU  \1F 
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\1A 


PRESS  <ENTER>  TO  VIEW  PLOT  \1F 


END 

inkey 

els 

rep  PROJA  DEFPLOT.DRS 
capture  G7  >NUL 
color  \1F 
els 

goto  -menu 


-proceed  ****  PROCEED  WITH  NEXT  SIMULATION  ******************** 
els 

color  \1F 
begtype 


************************************************* 
*  Press  <ENTER>  to  continue  * 

************************************************* 


end 

goto  -top 


-on . error- 

if  %R  >  82  if  %R  <  90  type  !!  Floating  Point  Error  !i  [goto  -Calc. 
Cls  beep  type  Unexpected  batch  file  error  %R  in  line  %L  |exit 
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APPENDIX  J:  PROJECT  DYNEX  FILE 


if  #tm<.l  then 
display  clear 

************************************** 

! ! ! !  Important  Points  to  Remember  1 ! ! ! 
************************************** 

~  You  are  not  allowed  to  discuss  this  exercise  with  anyone 
other  than  the  lab  attendant.  Please  refrain  from 
discussing  this  with  members  in  the  other  class  until  they 
have  completed  the  exercise. 

-  The  system  will  show  you  the  size  of  the  initial  core  team 
of  software  developers  who  have  just  completed  the 
requirements /design  specifications.  You  will  then  be  asked 
for  your  desired  staffing  level  for  the  programming  phase. 
Then,  the  system  will  run  through  the  first  simulation  time 
period  (40  working  days)  and  allow  you  to  view  various 
reports  and  graphs.  You  will  then  be  allowed  to  update  your 
estimates  for  project  cost  and  duration  and  change  your 
staffing  levels. 

-  Record  your  decision  for  each  interval  on  the 
documentation  sheet  provided  before  proceeding  to  the  next 
interval . 


THE  LAB  ATTENDANT  MUST  VERIFY  YOUR  FINAL  RESULTS! 

-  GOOD  LUCK!  Press  <ENTER>  to  continue. 

dendq 

choice  1 

cend  1/1 


display  clear 
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************************************************************ 

*  INITIAL  ESTIMATES  FOR  THIS  PROJECT:  * 

* 

*  System  Size  42000.  DSI  * 

*  Cost  of  Programming  Phase  #T0TMD1  Person  Days  * 

*  Duration  of  Programming  Phase  #TDEV  Days  * 

*  * 

*  The  initial  core  team  of  software  developers  who  have* 

*  just  completed  the  reguirements  and  design  * 

*  specifications  is  #WFS1  people.  * 

*  * 

*  Your  task  is  to  take  over  as  manager  of  the  * 

*  programming  phase.  At  this  point,  you  need  to  make  2* 

*  decisions:  * 

*  * 

*  1.  The  total  staff  level  for  the  programming  phase.  * 

*  * 

*  2.  The  percent  of  this  staff  to  allocate  to  Quality  * 

*  Assurance .  ^ 

************************************************************ 


- >  FIRST  DECISION:  The  total  staff  level 

Enter  your  total  reguested  staff  level  and  press  <ENTER>. 
dendg 

dq  WFS1=0.5< 
display  clear 


- >  SECOND  DECISION: 

NEW  tool's  estimate  for  the  percent  of  the  total  staff  to 
allocate  to  QA  is  #FRMPQA  percent.  Remember,  NEW_TOOL  has 
not  yet  been  calibrated  to  your  environment.  Thus,  this 
estimate  is  merely  illustrative.  It  may  or  may  not  be 
appropriate  for  your  unique  project. 

1)  Enter  a  different  desired  percentage  (a  number  from  0  - 
100)  and  press  <ENTER>. 

OR 

2)  Press  <ENTER>  to  allocate  #FRMPQA  percent  of  your  staff 
to  QA. 

dendg 

dq  FRMPQA=0<100 
display  clear 

Your  total  requested  staffing  level  =  #WFS1 
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people. 

The  percent  to  be  devoted  to  QA  activities  =  #FRMPQA 
percent . 

(This  means  that  you  are  devoting  #WFS1  *  #FRMPQA  /  100  = 

#WFS1*FRMPQA/100  people  to  QA) 


******************************************************** 

*  ! !  IMPORTANT  ! !  * 

*  * 

*  This  is  your  final  opportunity  to  check  and  * 

*  change  the  values  for  this  period.  * 

*  * 

*  Press  1  then  <ENTER>  to  change  these  values.  * 

*  * 

*  If  all  values  are  correct,  record  them  on  * 

*  the  documentation  sheet  provided  then  * 

*  * 

*  Press  2  then  <ENTER>  to  continue.  * 

*  * 
******************************************************** 
dend 

choice  2 

display 

Your  total  requested  staffing  level  = 
dendq 

dq  WFS1=0.5< 
display 

The  percent  allocated  to  QA  = 
dendq 

dq  FRMPQA=0<100 

cend 

cend 

else 

choice  1 
cend  1/1 
display  clear 

************************************************** 

*  Make  Your  Desired  Changes  To  The  Variables  * 

*  and  press  <ENTER>  * 

*  OR  * 

*  Press  <ENTER>  to  keep  the  displayed  value  * 
************************************************** 


Your  updated  estimate  for  project  cost  (person  days) 
dendq 

dq  TOTMD1=0< 
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display 

Your  updated  estimate  for  project  duration  (days)  = 
dendq 

dq  PROJDR=0< 
display 

Your  total  requested  staffing  level  = 
dendq 

dq  WFS1=0.5< 
display 

The  percent  to  allocate  to  QA  (a  number  from  0  -  100)  = 
dendq 

dq  FRMPQA=0<100 


display  clear 

Your  updated  estimate  for  project  cost  =  #TOTMDl 

person  days 

Your  updated  estimate  for  project  duration  =  #PROJDR 

days 

Your  total  requested  staffing  level  =  #WFS1 

people 

The  percent  to  be  devoted  to  QA  activities  =  #FRMPQA 

percent 

(This  means  that  you  are  devoting  #WFS1  *  #FRMPQA  /  100  - 

#WFS1*FRMPQA/100  people  to  QA) 


******************************************************** 

*  1 !  IMPORTANT  ! !  * 

*  * 

*  This  is  your  final  opportunity  to  check  and  * 

*  change  the  values  for  this  period.  * 

*  * 

*  Press  1  then  <ENTER>  to  change  these  values.  * 

*  * 

*  If  all  values  are  correct,  record  them  on  * 

*  the  documentation  sheet  provided  then  * 

j.  * 

* 

*  Press  2  then  <ENTER>  to  continue.  * 

*  * 
******************************************************** 
dend 

choice  2 


display 

The  updated  estimate  for  project  cost  (person  days)  = 
dendq 
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dq  TOTMD1=0< 


display 

The  updated  estimate  for  project  duration  (days)  = 
dendq 

dq  PROJDR=0< 
display 

Your  total  requested  staffing  level  = 
dendq 

dq  WFS1=0.5< 
display 

The  percent  allocated  to  QA  = 
dendq 

dq  FRMPQA=0<100 

cend 

cend 

end 

display 

************************************************************ 

*  Press  <ENTER>  to  simulate  this  interval  and  return  to  * 

*  the  menu.  * 

*  * 
************************************************************ 
dendq 

choice  1 
display  clear 

******************************************** 


*  There  will  be  a  short  pause  while 

*  the  model  simulates  the  next  period. 


******************************************** 

dendq 

report 

t ime=maxt ime , 
cend  1/1 

spec  md_length=#length+40 


61 


APPENDIX  K:  UNCERTAINTY  GROUP  INSTRUCTION  SET  (Al) 

Your  Name:  _ _ _  A.1 

SMC  No.:  _ 

1.  Introduction 

The  exercise  you  are  about  to  undertake  is  similar  in  many  ways  to  flight  simulators 
that  pilots  use  to  mimic  flying  an  aircraft  from  takeoff  at  point  A  to  landing  at  point  B. 
Instead  of  flying  an  aircraft,  though,  the  simulator  mimics  the  programming  phase  of  a  real 
software  project.  In  this  simulation,  you  will  be  more  than  an  observer.  In  fact,  you  will 
play  the  role  of  manager  of  the  programming  phase  of  the  project.  Specifically,  your  role 
will  be  to  track  the  progress  of  the  project  by  reviewing  status  reports  and  graphs  available 
every  two-month  interval  (40  working  days)  during  the  programming  phase.  As  the 
manager,  you  must  then  make  two  staffing  decisions: 

First,  the  total  number  of  staff  you  need.  (You  can  hire  additional  staff, 
or  decrease  the  staffing  level  as  you  deem  necessary  to  complete  your 
programming  task  successfully.) 

Second,  you  need  to  decide  on  what  percent  of  your  total  staff  to  allocate 
to  the  Quality  Assurance  activity  to  be  conduct^  throughout  the  programming 
phase  (e.g.  to  do  inspections). 

2.  Project 

The  project  that  you  will  manage  happens  to  have  been  a  real  project  conducted  in  a 
real  organization.  For  the  project,  you  will  be  given  a  project  profile  containing  the 
following  initial  information: 

Estimated  Size  of  the  System:  in  Delivered  Source  Instructions  (DSI) 

Estimated  Cost  of  Programming  Phase:  in  Number  of  Person  Days 

Estimated  Duration  of  Programming  Phase:  in  Number  of  Work  Days 

Size  of  initial  Core  Team:  in  People 

The  Core  Team  is  a  skeleton  staff  of  software  professionals  who  are  there  to  ensure 
continuity  between  the  requirements/design  phase  (which  you  may  assume  has  just  been 
completed),  and  the  programming  phase  you  are  to  manage. 

The  cost  and  schedule  estimates  are  derived  from  a  new  off-the-shelf  estimation  tool, 
call  it  "NEW_TOOL",  that  has  been  recently  acquired. 

Historically,  the  defect  density  (i.e.  number  of  defects  detected  during  programming 
divided  by  the  number  of  KDSI  developed)  has  ranged  from  5-20  Defects/KDSI. 
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3.  Your  task 


Your  task  at  every  40-day  interval  is  to  review  the  project’s  status,  and  to  make  any 
necessary  adjustments  to  the  staffing  level  and  its  allocation.  In  order  to  do  so,  you  may  feel 
that  is  necessary  to  first  adjust  the  project’s  cost  and  duration  targets.  The  staffing  decision 
should  be  done  as  follows: 

1.  Decide  on  the  total  staffing  level,  and 

2.  Decide  on  what  percentage  of  the  staff  should  be  allocated  to  the  quality  assurance 
function  (i.e.  a  number  between  0  and  100). 

4.  Your  Goal  for  the  Task: 


Minimize  overruns  in  both  cost  and  schedule. 


Your  grade  for  the  simulation  will  be  based  on  an  equal  weighing  of  these  two  factors. 

5.  Some  Important  Points  to  Consider  in  Managing  Your  Task 

1.  As  the  manager  of  the  programming  phase,  you  specify  the  desired  staffing  level. 
You  may  find  that  your  actual  staffing  level  (as  it  will  appear  in  the  reports)  is 
different  from  what  you  requested.  This  would  be  due  to  the  delay  in  hiring 
people.  For  modest  additions  to  your  staffing,  the  average  hiring  delay  will  be 
around  40  days.  However  if  you  request  a  large  number  of  additional  staff,  the 
average  hiring  delay  will  be  much  longer. 

2.  Once  new  people  are  hired,  they  must  be  trained  and  assimilated.  The 
assimilation/tiaining  period  is  typically  80  days.  During  this  assimilation/training 
period  you  can  expect  the  new  employee  to  be  only  half  as  productive  as  an 
experienced  employee. 

3.  The  staff  size  that  you  select,  and  which  appears  in  reports,  may  show  fractions 
(e.g.  4.5  people)  since  people  are  allowed  to  work  on  more  than  one  project. 

4.  Adding  more  people  increases  communication  and  coordination  overhead  as 
happens  in  reality. 
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5.  You  will  need  to  take  into  account  the  possibility  of  losing  people  due  to  turnover. 
You  will  receive  a  staff  loss  notice  once  a  turnover  occurs. 

6.  Rules  of  the  Game 

1.  You  must  work  alone.  At  no  time  are  you  to  discuss  the  progress  of  the  project 
with  anyone. 

2.  If  you  have  a  question,  ask  the  lab  attendant. 

3  You  are  not  allowed  to  bring  any  notes  or  other  "gouge"  to  use  during  the 
simulation.  Feel  free  to  write  on  the  documentation  sheets  provided. 

4.  A  calculator  is  allowed  and  recommended. 

7.  Instructions  for  Starting  the  System 

Follow  the  instructions  Carefully.  If  any  problems  arise,  immediately  seek  out  the  lab 
attendant. 

1.  Insert  the  disk  into  the  B:  drive.  Do  not  remove  the  disk  from  the  drive! 

2.  From  the  C:\  prompt,  type  B:  Do  NOT  start  the  network! 

3.  Start  the  simulation  by  typing  START  at  the  B:\  prompt. 

4.  Follow  the  instructions  as  they  appear  on  the  screen. 

5.  The  simulation  is  complete  when  the  %  Programming  Reported  Complete  in 
the  PROJECT  STATUS  REPORT  is  100%.  When  this  occurs  Call  the  lab 
attendant. 
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Your  Name: 
SMC  No.: 


YOUR  GOAL  IS: 


Minimize  overruns  in  both  cost  and  schedule. 


INITIAL  ESTIMATES: 


Project  Size  42,000  DSI 

Project  Cost  1887  Person  Days 

Project  Duration  (start-end)  237  Days 


TIME  ELAPSED 
(DAYS) 

ESTIMATED 

COST 

(PERS-DAYS) 

ESTIMATED 

DURATION 

(DAYS) 

STAFFING 

LEVEL 

(PERSONS) 

QUALITY 

ASSURANCE 

(PERCENT) 

Initial  Decision 

1887 

237 

Time  Elapsed  -  40  Days 

Time  Elapsed  -  80  Days 

Time  Elapsed  -  120  Days 

Time  Elapsed  -  160  Days 

Time  Elapsed  -  200  Days 

Time  Elapsed  -  240  Days 

Time  Elapsed  -  280  Days 

Time  Elapsed  -  320  Days 

Time  Elapsed  -  360  Days 

Time  Elapsed  -  400  Days 

Time  Elapsed  -  440  Days 

Time  Elapsed  -  480  Days 

Time  Elapsed  -  520  Days 

i  i  T~M-v  A 

ikTnn  all* 4' •&* 

*♦♦♦  whLN  VOU  AriTdone,  call  the  lab  ATTENDAN  1 


66 


APPENDIX  L;  RISK  GROUP  INSTRUCTION  SET  (A2) 


Your  Name: 
SMC  No.: 


1.  Introduction 

The  exercise  you  are  about  to  undertake  is  similar  in  many  ways  to  flight  simulators 
that  pilots  use  to  mimic  flying  an  aircraft  from  takeoff  at  point  A  to  landing  at  point  B. 
Instead  of  flying  an  aircraft,  though,  the  simulator  mimics  the  programming  phase  of  a  real 
software  project.  In  this  simulation,  you  will  be  more  than  an  observer.  In  fact,  you  will 
play  the  role  of  manager  of  the  programming  phase  of  the  project.  Specifically,  your  role 
will  be  to  track  the  progress  of  the  project  by  reviewing  status  reports  and  graphs  available 
every  two-month  interval  (40  working  days)  during  the  programming  phase.  As  the 
manager,  you  must  then  make  two  staffing  decisions: 

First,  the  total  number  of  staff  you  need.  (You  can  hire  additional  staff, 
or  decrease  the  staffing  level  as  you  deem  necessary  to  complete  your 
programming  task  successfully.) 

Second,  you  need  to  decide  on  what  percent  of  your  total  staff  to  allocate 
to  the  Quality  Assurance  activity  to  be  conducted  throughout  the  programming 
phase  (e.g.  to  do  inspections). 

2.  Project 

The  project  that  you  will  manage  happens  to  have  been  a  real  project  conducted  in  a 
real  organization.  For  Ae  project,  you  will  be  given  a  project  profile  containing  the 
following  initial  information: 

Estimated  Size  of  the  System:  in  Delivered  Source  Instructions  (DSI) 

Estimated  Cost  of  Programming  Phase:  in  Number  of  Person  Days 

Estimated  Duration  of  Programming  Phase:  in  Number  of  Work  Days 

Size  of  initial  Core  Team:  in  People 

The  Core  Team  is  a  skeleton  staff  of  software  professionals  who  are  there  to  ensure 
continuity  between  the  requirements/design  phase  (which  you  may  assume  has  just  been 
completed),  and  the  programming  phase  you  are  to  manage. 

The  cost  and  schedule  estimates  are  derived  from  a  new  off-the-shelf  estimation  tool, 
call  it  "NEW_TOOL",  that  has  been  recently  acquired. 

Historically,  the  defect  density  (i.e.  number  of  defects  detected  during  programming 
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divided  by  the  number  of  KDSI  developed)  has  ranged  from  5  -  20  Defects/KDSI. 

3.  Your  task 

Your  task  at  every  40-day  interval  is  to  review  the  project’s  status,  and  to  make  any 
necessary  adjustments  to  the  staffing  level  and  its  allocation.  In  order  to  do  so,  you  may  feel 
that  is  necessary  to  first  adjust  the  project’s  cost  and  duration  targets.  The  staffing  decision 
should  be  done  as  follows: 

1.  Decide  on  the  total  staffing  level,  and 

2.  Decide  on  what  percentage  of  the  staff  should  be  allocated  to  the  quality  assurance 
function  (i.e.  a  number  between  0  and  100). 

4.  Your  Goal  for  the  Task: 


Minimize  Overruns  in  both  cost  and  schedule. 


Your  grade  for  the  simulation  will  be  based  on  an  equal  weighing  of  these  two  factors. 

5.  Some  Important  Points  to  Consider  in  Managing  Your  Task 

1.  As  the  manager  of  the  programming  phase,  you  specify  the  desired  staffing  level. 
You  may  find  that  your  actual  staffing  level  (as  it  will  appear  in  the  reports)  is 
different  from  what  you  requested.  This  would  be  due  to  the  delay  in  hiring 
people.  For  modest  additions  to  your  staffing,  the  average  hiring  delay  will  be 
around  40  days.  However  if  you  request  a  large  number  of  additional  staff,  the 
average  hiring  delay  will  be  much  longer. 

2.  Once  new  people  are  hired,  they  must  be  trained  and  assimilated.  The 
assimilation/training  period  is  typically  80  days.  During  this  assimilation/training 
period  you  can  expect  the  new  employee  to  be  only  half  as  productive  as  an 
experienced  employee. 

3.  The  staff  size  that  you  select,  and  which  appears  in  reports,  may  show  fractions 
(e.g.  4.5  people)  since  people  are  allowed  to  work  on  more  than  one  project. 

4.  Adding  more  people  increases  communication  and  coordination  overhead  as 
happens  in  reality. 
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5.  A  project  risk  in  this  organization  is  that  of  losing  people  due  to  turnover. 
Historically,  the  turnover  rate  averages  to  1.5  people  lost  every  reporting  period 
(i.e.,  every  40  days). 

The  following  are  the  probabilities  of  possible  staff  losses  every  40  day  period: 

25  %  probability  of  no  loss  in  staff. 

25  %  probability  of  1  person  lost. 

25  %  probability  of  2  people  lost. 

25  %  probability  of  3  people  lost. 

You  will  receive  a  staff  loss  notice  once  a  turnover  occurs. 

6.  Rules  of  the  Game 

1.  You  must  work  alone.  At  no  time  are  you  to  discuss  the  progress  of  the  project 
with  anyone. 

2.  If  you  have  a  question,  ask  the  lab  attendant. 

3  You  are  not  allowed  to  bring  any  notes  or  other  "gouge"  to  use  during  the 
simulation.  Feel  free  to  write  on  the  documentation  sheets  provided. 

4.  A  calculator  is  allowed  and  recommended. 

7.  Instructions  for  Starting  the  System 

Follow  the  instructions  Carefiillv.  If  any  problems  arise,  immediately  seek  out  the  lab 
attendant. 

1.  Insert  the  disk  into  the  B:  drive.  Do  not  remove  the  disk  from  the  drive! 

2.  From  the  C:\  prompt,  type  B:  Do  NOT  start  the  network! 

3.  Start  the  simulation  by  typing  START  at  the  B:\  prompt. 

4.  Follow  the  instructions  as  they  appear  on  the  screen. 

5.  The  simulation  is  complete  when  the  %  Programming  Reported  Complete  in 
the  PROJECT  STATUS  REPORT  is  100%.  When  this  occurs  Call  the  lab 
attendant. 
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Your  Name: 
SMC  No.: 


YOUR  GOAL  IS: 


Minimize  overruns  in  both  cost  and  schedule. 


INITIAL  ESTIMATES: 

Project  Size 
Project  Cost 

Project  Duration  (start-end) 


42,000  DSI 
1887  Person  Days 
237  Days 


APPENDIX  M;  CERTAINTY  GROUP  INSTRUCTION  SET  (Bl) 


Your  Name:  _ _ 

SMC  No.:  _ 

1.  Introduction 

The  exercise  you  are  about  to  undertake  is  similar  in  many  ways  to  flight  simulators 
that  pilots  use  to  mimic  flying  an  aircraft  from  takeoff  at  point  A  to  landing  at  point  B. 
Instead  of  flying  an  aircraft,  though,  the  simulator  mimics  the  programming  phase  of  a  real 
software  project.  In  this  simulation,  you  will  be  more  than  an  observer.  In  fact,  you  will 
play  the  role  of  manager  of  the  programming  phase  of  the  project.  Specifically,  your  role 
wiU  be  to  track  the  progress  of  the  project  by  reviewing  status  reports  and  graphs  available 
every  two-month  interval  (40  working  days)  during  the  programming  phase.  As  the 
manager,  you  must  then  make  two  staffing  decisions. 

First,  the  total  number  of  staff  you  need.  (You  can  hire  additional  staff, 
or  decrease  the  staffing  level  as  you  deem  necessary  to  complete  your 
programming  task  successfully.) 

Second,  you  need  to  decide  on  what  percent  of  your  total  staff  to  allocate 
to  the  Quality  Assurance  activity  to  be  conducted  throughout  the  programming 
phase  (e.g.  to  do  inspections). 

2.  Project 

The  project  that  you  will  manage  happens  to  have  been  a  real  project  conducted  in  a 
real  organization.  For  the  project,  you  will  be  given  a  project  profile  containing  the 
following  initial  information: 

Estimated  Size  of  the  System:  in  Delivered  Source  Instructions  (DSI) 

Estimated  Cost  of  Programming  Phase:  in  Number  of  Person  Days 

Estimated  Duration  of  Programming  Phase:  in  Number  of  Work  Days 

Size  of  initial  Core  Team:  in  People 

The  Core  Team  is  a  skeleton  staff  of  software  professionals  who  are  there  to  ensure 
continuity  between  the  requirements/design  phase  (which  you  may  assume  has  just  been 
completed),  and  the  programming  phase  you  are  to  manage. 

The  cost  and  schedule  estimates  are  derived  from  a  new  off-the-shelf  estimation  tool, 
call  it  "NEW_TOOL",  that  has  been  recently  acquired. 

Historically,  the  defect  density  (i.e.  number  of  defects  detected  during  programming 
divided  by  the  number  of  KDSI  developed)  has  ranged  from  5-20  Defects/KDSI. 
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3.  Your  task 


Your  task  at  every  40-day  interval  is  to  review  the  project’s  status,  and  to  make  any 
necessary  adjustments  to  the  staffing  level  and  its  allocation.  In  order  to  do  so,  you  m^  feel 
that  is  necessary  to  first  adjust  the  project’s  cost  and  duration  targets.  The  staffing  decision 
should  be  done  as  follows: 

1.  Decide  on  the  total  staffing  level,  and 

2.  Decide  on  what  percentage  of  the  staff  should  be  allocated  to  the  quality  assurance 
function  (i.e.  a  number  between  0  and  100). 

4.  Your  Goal  for  the  Task: 


Minimize  overruns  in  both  cost  and  schedule. 


Your  grade  for  the  simulation  will  be  based  on  an  equal  weighing  of  these  two  factors. 

5.  Some  Important  Points  to  Consider  in  Managing  Your  Task 

1.  As  the  manager  of  the  programming  phase,  you  specify  the  desired  staffing  level. 
You  may  find  that  your  actual  staffing  level  (as  it  will  appear  in  the  reports)  is 
different  from  what  you  requested.  This  would  be  due  to  the  delay  in  hiring 
people.  For  modest  additions  to  your  staffing,  the  average  hiring  delay  will  be 
around  40  days.  However  if  you  request  a  large  number  of  additional  staff,  the 
average  hiring  delay  will  be  much  longer. 

2.  Once  new  people  are  hired,  they  must  be  trained  and  assimilated.  The 
assimilation/ training  period  is  typically  80  days.  During  this  assimilation/training 
period  you  can  expect  the  new  employee  to  be  only  half  as  productive  as  an 
experienced  employee. 

3.  The  staff  size  that  you  select,  and  which  appears  in  reports,  may  show  fractions 
(e.g.  4.5  people)  since  people  are  allowed  to  work  on  more  than  one  project. 

4.  Adding  more  people  increases  communication  and  coordination  overhead  as 
happens  in  reality. 
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5.  A  project  risk  in  this  organization  is  that  of  losing  people  due  to  turnover. 
Historically,  the  turnover  rate  averages  to  1.5  people  lost  every  reporting  period 
(i.e.,  every  40  days). 

To  minimize  the  negative  impacts  of  staff  turnover  on  a  project,  the 
organization  has  instituted  a  policy  of  requiring  a  40  day  notice  of  leaving.  As  the 
project  manager,  this  guarantees  that  you  will  be  aware  of  any  staff  losses  in  a  40 
day  period  at  the  beginning  of  the  period. 

You  will  receive  a  staff  loss  notice  once  an  employee  plans  to  leave. 

6.  Rules  of  the  Game 

1.  You  must  work  alone.  At  no  time  are  you  to  discuss  the  progress  of  the  project 
with  anyone. 

2.  If  you  have  a  question,  ask  the  lab  attendant. 

3  You  are  not  allowed  to  bring  any  notes  or  other  "gouge"  to  use  during  the 
simulation.  Feel  free  to  write  on  the  documentation  sheets  provided. 

4.  A  calculator  is  allowed  and  recommended. 

7.  Instructions  for  Starting  the  System 

Follow  the  instructions  Carefully.  If  any  problems  arise,  immediately  seek  out  the  lab 
attendant. 

1.  Insert  the  disk  into  the  B:  drive.  Do  not  remove  the  disk  from  the  drive! 

2.  From  the  C:\  prompt,  type  B:  Do  NOT  start  the  network! 

3.  Start  the  simulation  by  typing  START  at  the  B:\  prompt. 

4.  Follow  the  instructions  as  they  appear  on  the  screen. 

5.  The  simulation  is  complete  when  the  %  Programming  Reported  Complete  in 
the  PROJECT  STATUS  REPORT  is  100%.  When  this  occurs  Call  the  lab 
attendant. 
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Your  Name: 
SMC  No.: 


YOUR  GOAL  IS: 


Minimize  ovemins  in  both  cost  and  schedule. 


INITIAL  ESTIMATES: 

Project  Size 
Project  Cost 

Project  Duration  (start-end) 


42,000  DSI 
1887  Person  Days 
237  Days 


TIME  ELAPSED 
(DAYS) 


Initial  Decision 


Time  Elapsed  -  40  Days 


Time  Elapsed  -  80  Days 


Time  Elapsed  -  120  Days 


Time  Elapsed  -  160  Days 


Time  Elapsed  -  200  Days 


Time  Elapsed  -  240  Days 


ESTIMATED 

COST 

(PERS-DAYS) 


ESTIMATED 

DURATION 

(DAYS) 


STAFFING 

LEVEL 

(PERSONS) 


QUALITY 

ASSURANCE 

(PERCENT) 


Time  Elapsed  -  280  Days 


Time  Elapsed  -  320  Days 


Time  Elapsed  -  360  Days 


Time  Elapsed  -  400  Days 


Time  Elapsed  -  440  Days 


Time  Elapsed  -  480  Days 


Time  Elapsed  -  520  Days 


*otwhEN  y 


RE  DONE.  CALL  THE  LAB  ATTENDANT  **** 


APPENDK  N:  PRACTICE  EXPERIMENT  INSTRUCTION  SET 


Your  Name:  _ _ 

SMC  No.:  _ _ 

1.  Introduction 

The  exercise  you  are  about  to  undertake  is  similar  in  many  ways  to  flight  simulators 
that  pilots  use  to  mimic  flying  an  aircraft  from  takeoff  at  point  A  to  landing  at  point  B. 
Instead  of  flying  an  aircraft,  though,  the  simulator  mimics  the  programming  phase  of  a  real 
software  project.  In  this  simulation,  you  will  be  more  than  an  observer.  In  fact,  you  will 
play  the  role  of  manager  of  the  programming  phase  of  the  project.  Specifically,  your  role 
will  be  to  track  the  progress  of  the  project  by  reviewing  status  reports  and  graphs  available 
every  two-month  interval  (40  working  days)  during  the  programming  phase.  As  the 
manager,  you  must  then  make  two  staffing  decisions: 

First,  the  total  number  of  staff  you  need.  (You  can  hire  additional  staff, 
or  decrease  the  staffing  level  as  you  deem  necessary  to  complete  your 
programming  task  successfully.) 

Second,  you  need  to  decide  on  what  percent  of  your  total  staff  to  allocate 
to  the  Quality  Assurance  activity  to  be  conducted  throughout  the  programming 
phase  (e.g.  to  do  inspections). 

2.  Project 

The  project  that  you  will  manage  happens  to  have  been  a  real  project  conducted  in  a 
real  organization.  For  the  project,  you  will  be  given  a  project  profile  containing  the 
following  initial  information: 

Estimated  Size  of  the  System:  in  Delivered  Source  Instructions  (DSI) 

Estimated  Cost  of  Programming  Phase:  in  Number  of  Person  Days 

Estimated  Duration  of  Programming  Phase:  in  Number  of  Work  Days 

Size  of  initial  Core  Team:  in  People 

The  Core  Team  is  a  skeleton  staff  of  software  professionals  who  are  there  to  ensure 
continuity  between  the  requirements/design  phase  (which  you  may  assume  has  just  been 
completed),  and  the  programming  phase  you  are  to  manage. 

The  cost  and  schedule  estimates  are  derived  from  a  new  off-the-shelf  estimation  tool, 
call  it  "NEW_TOOL",  that  has  been  recently  acquired. 

Historically,  the  defect  density  (i.e.  number  of  defects  detected  during  programming 
divided  by  the  number  of  KDSI  developed)  has  ranged  from  5-20  Defects/KDSI. 
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3.  Your  task 


Your  task  at  every  40-day  interval  is  to  review  the  project’s  status,  and  to  make  any 
necessary  adjustments  to  the  staffing  level  and  its  allocation.  In  order  to  do  so,  you  may  feel 
that  is  necessary  to  first  adjust  the  project’s  cost  and  duration  targets.  The  staffing  decision 
should  be  done  as  follows: 

1.  Decide  on  the  total  staffing  level,  and 

2.  Decide  on  what  percentage  of  the  staff  should  be  allocated  to  the  quality  assurance 
function  (i.e.  a  number  between  0  and  100). 

4.  Your  Goal  for  the  Task; 


Familiarize  yourself  with  the  simulation. 


5.  Some  Important  Points  to  Consider  in  Managing  Your  Task 

1.  As  the  manager  of  the  programming  phase,  you  specify  the  desired  staffing  level. 
You  may  find  that  your  actual  staffing  level  (as  it  will  appear  in  the  reports)  is 
different  from  what  you  requested.  This  would  be  due  to  the  delay  in  hiring 
people.  For  modest  additions  to  your  staffing,  the  average  hiring  delay  will  be 
around  40  days.  However  if  you  request  a  large  number  of  additional  staff,  the 
average  hiring  delay  will  be  much  longer. 

2.  Once  new  people  are  hired,  they  must  be  trained  and  assimilated.  The 
assimilation/training  period  is  typically  80  days.  During  this  assimilation/training 
period  you  can  expect  the  new  employee  to  be  only  half  as  productive  as  an 
experienced  employee. 

3.  The  staff  size  that  you  select,  and  which  appears  in  reports,  may  show  fractions 
(e.g.  4.5  people)  since  people  are  allowed  to  work  on  more  than  one  project. 

4.  Adding  more  people  increases  communication  and  coordination  overhead  as 
happens  in  reality. 
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6.  Rules  of  the  Game 


1.  You  must  work  alone.  At  no  time  are  you  to  discuss  the  progress  of  the  project 
with  anyone. 

2.  If  you  have  a  question,  ask  the  lab  attendant. 

3  You  are  not  allowed  to  bring  any  notes  or  other  "gouge"  to  use  during  the 
simulation.  Feel  free  to  write  on  the  documentation  sheets  provided. 

4.  A  calculator  is  allowed  and  recommended. 

7.  Instructions  for  Starting  the  System 

Follow  the  instructions  Carefully.  If  any  problems  arise,  immediately  seek  out  the  lab 
attendant. 

1.  Insert  the  disk  into  the  B:  drive.  Do  not  remove  the  disk  from  the  drive! 

2.  From  the  C:\  prompt,  type  B:  Do  NOT  start  the  network! 

3.  Start  the  simulation  by  typing  PRACTICE  at  the  B:\  prompt. 

4.  Follow  the  instructions  as  they  appear  on  the  screen. 

5.  The  simulation  is  complete  when  the  %  Programming  Reported  Complete  in 
the  PROJECT  STATUS  REPORT  is  100%.  When  this  occurs  Call  the  lab 
attendant. 
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Your  Name: 
SMC  No.: 


YOUR  GOAL  IS: 


Familiarize  yourself  with  the  sunulation. 


INITIAL  ESTIMATES: 

Project  Size 
Project  Cost 

Project  Duration  (start-end) 


ESTIMATED 

DURATION 

(DAYS) 


20,000  DSI 
1400  Person  Days 
350  Days 


STAFFING  QUALITY 

LEVEL  ASSURANCE 

(PERSONS)  (PERCENT) 


520  Days 


H 


RET)ONE.  CALLTBELAB^TTENDANT**** 


APPENDIX  O:  GRAPHS. DRS  FILES 

STATPLOT.DRS 

plotxy  <TM"TIME  (DAYS)  ",0,600> ,  <FTEQWF"TOTAL  STAFF  (PERSONS) 
",0,40>, 

<PJBSZT/1000"EST  SYSTEM  SIZE  (KDSI)  ",0,80 >, 

<JBSZMD"EST  PROGRAMMING  COST  (PERSON  DAYS)  ", 0,6000 > 

STAFPLOT.DRS 

plotxy  <TM"TIME  (DAYS)  ",0,600> ,  <FTEQWF"TOTAL  STAFF  (PERSONS) 
",0,40>, 

’<CRQAWF"QA  STAFF  (PERSONS)  ",0,40> ,  <CRDVWF"PROG  STAFF 
(PERSONS)  ",0,40 > 

DEFPLOT.DRS 

plotxy  <TM"TIME  (DAYS)  ", 0,600 >,<PRQAMD"QA  PERSON  DAYS  PER 
PERIOD  ", 0,240 >, 

<PRERD"DEFECTS  DETECTED  PER  PERIOD  ", 0,240 > 


79 


APPENDIX  P:  RANDOMIZATION  WORKSHEET 


Kelly,  John 

104 

King,  A. 

150 

Lamb,  V. 

015 

Langhorne,  W. 

020 

Larochelle,  L. 

816 

Lewis,  J. 

916 

Mancano,  V. 

691 

jMxchal ,  7  • 

141 

Nault,  M. 

625 

Oneill,  T. 

223 

Onorati,  A. 

465 

Pemberton,  L. 

255 

Prell,  M. 

853 

Robillard,  S. 

309 

Sears,  G. 

891 

Staten,  R* 

279 

Tate,  W. 

939 

Trepanier ,  D. 

241 

Weiss,  K. 

483 

Wilcox,  R. 

225 

Chou,  M. 

972 

Kelly,  James 

763 

Barnum,  T* 

648 

Berry,  E. 

151 

Bitzer,  S. 

248 

Callaghan,  V. 

493 

Cragmiles,  R. 

421 

Downs,  M. 

930 

Emde,  C. 

062 

Emswiler,  T. 

616 

Encinas,  T* 

078 

Franklin,  B. 

163 

Gregor ie,  J. 

394 

Hodges,  J. 

535 

Howard,  L. 

713 

Johnson,  S. 

375 

McGibbon,  H. 

399 

McQuay,  D. 

818 

Monroe,  W. 

166 

Swain,  W. 

917 

Tharpe ,  G . 

604 

81 


Both  Experiments  No  goals 

Experiments- 


A1  Uncertainty 
A2  Risk 
B1  Certainty 
Order 

1  C/S 

2  S/C 

+  No  goals  experiment 
*  Attend  but  not  in 


Not  in  McCaffrey* 


41  Students 


APPENDIX  Q:  PERFORMANCE  VARIABLES 


FNCOST 

Final 

FNSKED 

Final 

FNERR 

Final 

FNERG 

Final 

FNERD 

Final 

FNERES 

Final 

FNPRDT 

Final 

FNQAMD 

Final 

FNTRMD 

Final 

FNRWMD 

Final 

Cost  (Person  Days) 

Cumulative  Time  (Days) 

Errors  Remaining  Undetected 
Cumulative  Errors  Generated 
Cumulative  Errors  Detected 
Cumulative  Errors  Escaping  Detection 
Percentage  of  Errors  Detected 
Cumulative  Quality  Assurance  Person  Days 
Cumulative  Training  Person  Days 
Cumulative  Rework  Person  Days 
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Your  Ncime 
SMC  No,: 


APPENDIX  R:  PROJECT  QUESTIONNAIRE 


Group  All 

1,  In  making  your  decisions,  how  much  weight  out  of  100  points 
did  you  accord  to  the  following  goals?  (The  numbers  should  total 

100  points.) 

Cost  _ 


Schedule  _ 

100 

2.  Describe  (in  words,  numbers,  equation,  etc.)  what  decision  rule 
you  followed  in  deciding  on  the  overall  staffing  level  in  this 
project: 


3.  Please  try  to  elaborate  on  the  thinking  process  you  went 
through  in  making  your  decisions  in  this  project  (use  back  of  page 

if  necessary) : 


4.  Please  elaborate  on  how  you  handled  the  problem  of  staff 
turnover . 


5.  How  clear  were  the  instructions  regarding  the  task? 

123456789 
Not  at  all  Very 

Clear  Clear 
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To  what  extent  was  the  graphical  information  provided  on  the 
progress  of  the  project  helpful  in  improving  your  own  decisions 

1  23456789 

Not  at  all  very 

Helpful  Helpful 


To  what  extent  were  the  reports  on  the  progress  of  the  project 
helpful  in  improving  your  own  decisions? 

1  23456789 

Not  at  all  Very 

Helpful  Helpful 

In  the  project  that  you  just  completed,  did  you 

(a)  Use  the  PROJECT  STATUS  report  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


In  the  project  that  you  just  completed,  did  you 

(a)  Use  the  STAFFING  LEVEL  report  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


In  the  project  that  you  just  completed,  did  you 

(a)  Use  the  DEFECT  report  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


In  the  project  that  you  just  completed,  did  you 

(a)  Use  the  CUMULATIVE  report  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


In  the  project  you  just  completed,  did  you 

(a)  Use  the  PROJECT  STATUS  graph  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


In  the  project  that  you  just  completed,  did  you 

(a)  Use  the  STAFFING  LEVEL  graph  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


In  the  project  that  you  just  completed,  did  you 

(a)  Use  the  DEFECT  graph  (Y/N)?  _ 

(b)  If  you  did,  please  describe  how  you  used  the  information. 


Have  you  in  the  past  participated  in  project  management  (Y/N)? 

If  YES,  to  what  extent  was  the  task  in  this  simulation  similar  to 
your  previous  experience? 

1  23456789 

Not  at  all  Very 

Similar  Similar 


16. 


How  interesting  was  the  task  you  just  performed? 


1  2 
Not  at  all 
Interesting 


9 

Very 

Interesting 


How  serious  were  you  in  performing  the  task? 


1  2 
Not  at  all 
Serious 


9 

Very 

Serious 


How  clear  were  the  instructions  regarding  the  task,  generally? 


1  2 
Not  at  all 
Clear 


Clear 


How  easy  was  the  simulation  to  use? 


1  2 
Not  at  all 
Easy 


9 

Very 

Easy 


Please  give  us  some  information  about  yourself^ absolute 
confidence.  At  no  time  will  your  name  appear  in  the  results.  The 
data  will  only  be  used  in  an  aggregate  statistical  sense). 

(a)  Curriculum  enrolled  in:  _ _ _ _ _ 

(b)  Age  - - 

( c )  Sex  - 

(d)  Full  time  work  experience  (in  years)  _ _ 

(e)  How  long  ago  (in  years)  did  - - - 

you  complete  your 

undergraduate  education? 

(f)  How  familiar  are  you  with  computers,  generally? 

123456789 

Not  at  all  . 

Familiar  Famrlxar 

(g)  How  many  hours  {per  week)  do  you  use  computers? 
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21. 


Your  general  comments  regarding  the  simulation: 


***  END  OF  SIMULATION  *** 
Thank  you  for  your  participation. 
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APPENDIX  S:  FORMAT  OF  DEMOGRAPHIC  DATA 


QIS 

Question  1  Schedule  Percent 

QlQ 

Question  1  Quality  Percent 

QIC 

Question  1  Cost  Percent 

Q5 

Question  5  Response  (1-9) 

Q6 

Question  6  Response  (1-9) 

Q7 

Question  7  Response  (1-9) 

Q8 

Question  8  Response  (0/1  0-No  1-Yes) 

09 

Question  9  Response  (0/1  0-No  1-Yes) 

QIO 

Question  10  Response  (0/1  0-No  1-Yes) 

Qll 

Question  11  Response  (0/1  0-No  1-Yes) 

Q12 

Question  12  Response  (0/1  0-No  1-Yes) 

Q13 

Question  13  Response  (0/1  0-No  1-Yes) 

Q14 

Question  14  Response  (0-9  0-No  1-9  Yes  and  the  value) 

Q15 

Question  15  Response  (1-9) 

Q16 

Question  16  Response  (1-9) 

Q17 

Question  17  Response  (1-9) 

Q18 

Question  18  Response  (1-9) 

Q19 

Question  19  Response  (1-9) 

CURR 

Curriculum 

AGE 

Age  (years) 

SEX 

M=Male,  F= Female 

WKEXP 

Work  Experience  (years) 

EDAGO 

Years  since  undergraduate  education  was  completed 

FAM 

Computer  familiarity 

CHRSWK 

Number  of  computer  hours  per  week 
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1 

1995 


APPENDIX  T:  PERFORMANCE/DEMOGRAPHIC  DATA 

Risk  experiment:  Comparison  of  performance 

•  12:21  Tuesday,  July  25, 

-  PROJECT=A  RISKTyPE=R 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

FNCOST 

14 

2941.76 

523.7349118 

2256.31 

4146.24 

FNSKED 

14 

310.2142857 

43.5447225 

258.0000000 

390.5000000 

FNERR 

14 

14654.44 

9912.12 

2008.65 

32462.84 

FNERG 

14 

1819.48 

119.1415691 

1676.29 

2032.23 

FNERD 

14 

592.0057143 

369.7023526 

216.1100000 

1432.60 

FNERES 

14 

1227.47 

342.4663414 

409.1300000 

1608.85 

FNPRDT 

14 

32.2107143 

19.3308098 

12.0000000 

77.7900000 

FNQAMD 

14 

347.5107143 

267.8133500 

119.7700000 

1036.56 

FNTRMD 

14 

233.6628571 

39.3861243 

163.7800000 

316.1500000 

FNRWMD 

14 

426.0671429 

261.2214201 

168.4100000 

1006.00 

Q1 

14 

53.2142857 

10.6711586 

35.0000000 

70.0000000 

Q2 

14 

0 

0 

0 

0 

Q3 

14 

46.7857143 

10.6711586 

30.0000000 

65.0000000 

Q4 

14 

7.8571429 

1.7913099 

3.0000000 

9.0000000 

Q5 

14 

4.7857143 

3.2623392 

1.0000000 

9.0000000 

Q6 

14 

7.6428571 

2.0232169 

3.0000000 

9.0000000 

Q7 

14 

0.9285714 

0.2672612 

0 

1.0000000 

Q8 

14 

0.9285714 

0.2672612 

0 

1.0000000 

Q9 

14 

0.7142857 

0.4688072 

0 

1.0000000 

QIO 

14 

0.6428571 

0.4972452 

0 

1.0000000 

Qll 

14 

0.5000000 

0.5188745 

0 

1.0000000 

Q12 

14 

0.3571429 

0.4972452 

0 

1.0000000 

Q13 

14 

0.2857143 

0.4688072 

0 

1.0000000 

Q14 

14 

5.2142857 

3.5772480 

0 

9.0000000 

Q15 

14 

6.7142857 

1.8156826 

4.0000000 

9.0000000 

Q16 

14 

7.8571429 

1.1673206 

5.0000000 

9.0000000 

Q17 

14 

8.0714286 

1.3847680 

4.0000000 

9.0000000 

Q18 

14 

8.2857143 

1.4373358 

4.0000000 

9.0000000 

Q20 

14 

34.5000000 

5.3601091 

28.0000000 

44.0000000 

Q22 

14 

12.6071429 

6.1022649 

6.0000000 

26.0000000 

Q23 

14 

10.8214286 

5.4688177 

6.0000000 

23.0000000 

Q24 

14 

7.3571429 

1.7805420 

3.0000000 

9.0000000 

Q25 

14 

15.7857143 

12.0203582 

2.0000000 

50.0000000 

Risk  experiment:  Comparison  of  performance 


*  12:21  Tuesday,  July  25, 

1995 


PROJECT=A  RISKTypE=U 


Variable  N 


FNCOST  15 
FNSKED  15 


Mean 


3333.66 

339.1555556 


Std  Dev 


733.0443938 

54.8975766 


Minimum 


2468.45 

247.5416667 


Maximum 


4895.83 

451.7500000 
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3 


FNERR 

15 

FNERG 

15 

FNERD 

15 

FNERES 

15 

FNPRDT 

15 

FNQAMD 

15 

FNTRMD 

15 

FNRWMD 

15 

Q1 

15 

Q2 

15 

Q3 

15 

Q4 

15 

Q5 

15 

Q6 

15 

Q7 

15 

Q8 

15 

Q9 

15 

QIO 

15 

Qll 

15 

Q12 

15 

Q13 

15 

Q14 

15 

Q15 

15 

Q16 

15 

Q17 

15 

Q18 

15 

Q20 

15 

Q22 

15 

Q23 

15 

Q24 

15 

Q25 

15 

13414.73 

1730.40 

542.8013333 

1187.60 

31.8653333 

352.9280000 

231.2413333 

412.7433333 

51.6666667 

0 

48.3333333 

8.4000000 
5.1333333 
8.0000000 
1.0000000 
0.7333333 
0.5333333 
0.4000000 
0.5333333 
0.2666667 
0.3333333 
1.6000000 
7.8666667 
8.2000000 
8.5333333 
7.7333333 

34.9333333 

14.3333333 
13.2666667 

7.4000000 
28.1333333 


10470.29 

106.0497911 

416.9957476 

457.0779389 

25.6257889 

323.1240968 

37.6845861 

326.2204636 

9.9402980 

0 

9.9402980 

0.9856108 

3.2041640 

0.9258201 

0 

0.4577377 

0.5163978 

0.5070926 

0.5163978 

0.4577377 

0.4879500 

2.6672618 

1.3020131 

0.5606119 

0.6399405 

1.1629192 

6.0411289 

6.4660284 

6.1582310 

1.5491933 

19.9530401 


1710.86 

1591.83 

0 

429.0900000 

0 

0 

181.1500000 

0 

30.0000000 

0 

25.0000000 

6.0000000 

1.0000000 

7.0000000 

1.0000000 

0 

0 

0 

0 

0 

0 

0 

6.0000000 

7.0000000 

7.0000000 

5.0000000 

26.0000000 

5.0000000 

5.0000000 

3.0000000 

6.0000000 


30882.80 

1909.39 

1209.17 

1662.76 

73.8100000 

972.8700000 

302.9500000 

996.0900000 

75.0000000 

0 

70.0000000 

9.0000000 

9.0000000 

9.0000000 

1.0000000 

1.0000000 

1.0000000 

1.0000000 

1.0000000 

1,0000000 

1.0000000 

7.0000000 

9.0000000 

9.0000000 

9.0000000 

9.0000000 

47.0000000 

27.0000000 

25.0000000 

9.0000000 

90.0000000 


Risk  experiment:  Comparison  of  performance 

*  12:21  Tuesday^  July  25, 


1995 


PROJECT=B  RISKTYPE=C 


Variable 

N 

FNCOST 

12 

FNSKED 

12 

FNERR 

12 

FNERG 

12 

FNERD 

12 

FNERES 

12 

FNPRDT 

12 

FNQAMD 

12 

FNTRMD 

12 

FNRWMD 

12 

Ql 

12 

Q2 

12 

Q3 

12 

Q4 

12 

Q5 

12 

Q6 

12 

Q7 

12 

Mean 


2667.01 

274.6428571 

11559.47 

1711.85 

576.1850000 

1135.66 

33.9508333 

340.0333333 

262.0550000 

465.0475000 

56.6666667 

0 

43.3333333 

8.0000000 

4.9166667 

8.4166667 

1.0000000 


Std  Dev 


425.9057526 

47.4928566 

8144.78 

119.6097295 

218.4170454 

267.6175064 

13.4710818 

140.0635348 

44.6549005 

189.0080956 

11.5470054 

0 

11.5470054 

1.7056057 

2.4664414 

0.7929615 

0 


Minimum 


1705.57 

206.5714286 

2170.06 

1635.10 

0 

709.3500000 

0 

0 

184.1100000 

0 

40.0000000 

0 

20.0000000 

3.0000000 

1.0000000 

7.0000000 

1.0000000 


Maximum 


3299.61 

383.5714286 

31597.91 

1997.45 

925.7500000 

1737.02 

56.6200000 

594.1300000 

327.1300000 
788.1800000 

80.0000000 

0 

60.0000000 

9.0000000 

9.0000000 

9.0000000 

1.0000000 
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Q8 

12 

0.9166667 

0.2886751 

0 

1.0000000 

Q9 

12 

0.8333333 

0.3892495 

0 

1.0000000 

QIO 

12 

0.6666667 

0.4923660 

0 

1.0000000 

Qll 

12 

0.5000000 

0.5222330 

0 

1.0000000 

Q12 

12 

0.2500000 

0.4522670 

0 

1.0000000 

Q13 

12 

0.3333333 

0.4923660 

0 

1.0000000 

Q14 

12 

0.7500000 

2.5980762 

0 

9.0000000 

Q15 

12 

8.0833333 

1.3113722 

5.0000000 

9.0000000 

Q16 

12 

8.4166667 

0.7929615 

7.0000000 

9.0000000 

Q17 

12 

8.3333333 

0.9847319 

6.0000000 

9.0000000 

Q18 

12 

7.9166667 

1.4433757 

4.0000000 

9.0000000 

Q20 

12 

32.8333333 

3.2983008 

28.0000000 

39.0000000 

Q22 

12 

10.8333333 

3.8336627 

7.0000000 

20.0000000 

Q23 

12 

9.4166667 

2.9682665 

6.0000000 

16.0000000 

Q24 

12 

6.5000000 

1.1677484 

4.0000000 

8.0000000 

Q25 

12 

20.6666667 

7.7146064 

15.0000000 

40.0000000 

Risk  experiment: 


Comparison  of  performance 

'  12:21  Tuesday,  July  25, 


General  Linear  Models  Procedure 
Class  Level  Information 


Class 


Levels 


RISKTYPE 


Values 


C  R  U 


Number  of  observations  in  data  set  =  41 

Risk  experiment:  Comparison  of  performance 

*  12:21  Tuesday,  July  25, 


General  Linear  Models  Procedure 


Dependent  Variable:  FNCOST 

Source  DF 

F 


Model 

0.0187 

Error 


Corrected  Total 


R-Square 


Sum  of 
Squares 


40  16131243.07 


Mean 

Square  F  Value  Pr  > 


3047055.74  1523527.87  4.42 


38  13084187.33  344320.72 


Root  MSE 


FNCOST 


0.188892 


3004.72 


19.52887 


586.788 


Source 


DF 


Type  I  SS  Mean  Square  F  Value 


Pr  > 


F 


RISKTYPE 

0.0187 

Source 

F 

RISKTYPE 

0.0187 


2  3047055.74  1523527.87  4.42 

DF  Type  III  SS  Mean  Square  F  Value  Pr  > 

2  3047055.74  1523527.87  4.42 

Risk  experiment:  Comparison  of  performance 

*  12:21  Tuesday,  July  25, 


General  Linear  Models  Procedure 


Dependent  Variable:  FNSKED 

Source  DF 

F 


Sum  of 
Squares 


Mean 

Square  F  Value  Pr  > 


Model 

0.0066 

2 

27746.5886 

13873.2943 

5.75 

Error 

38 

91653.5577 

2411.9357 

Corrected  Total 

40 

119400.1463 

Mean 

R-Square 

C.V. 

Root  MSE 

FNSKED 

310.391 

0.232383 

15.82243 

49.1115 

Source 

F 

DF 

Type  I  SS 

Mean  Square 

F 

Value 

Pr  > 

RISKTYPE 

0.0066 

2 

27746.5886 

13873.2943 

5.75 

Source 

F 

DF 

Type  III  SS 

Mean  Square 

F 

Value 

Pr  > 

RISKTYPE 

2 

27746.5886 

13873.2943 

5.75 

0.0066 

7 

1995 


Risk  experiment:  Comparison  of  performance 

*  12:21  Tuesday,  July  25, 


General  Linear  Models  Procedure 
Dependent  Variable:  FNERR 


Source 

F 

Model 


Sum  of 
Squares 


Mean 

Square  F  Value  Pr  > 


2  62232814.9  31116407.4  0.33 


96 


0,7182 


Error 

38 

3541740642.9 

93203701.1 

Corrected  Total 

40 

3603973457.7 

Mean 

R-Square 

C.V. 

Root  MSE 

FNERR 

13295.0 

0.017268 

72.61508 

9654.21 

Source 

F 

DF 

Type  I  SS 

Mean  Square 

F 

Value 

Pr  > 

RISKTYPE 

0.7182 

2 

62232814.9 

31116407.4 

0.33 

Source 

F 

DF 

Type  III  SS 

Mean  Square 

F 

Value 

Pr  > 

RISKTYPE 

2 

62232814.9 

31116407.4 

0.33 

0.7182 
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